About java program.

[Joerg Meier]

[...]
Personally, I found your example considerably harder to read than the one
liner, as well as harder to read than what would have been my solution:

private boolean askYesNoquestion (String str){
if(str.equals("yes"))
return true;

return false;
}

Or, for even greater clarity:

Obviously, in the case of booleans, this style is superfleous (and
especially in something this simple), but I was trying to demonstrate the
style, not write a better askYesNoquestion method.

However, as for returning true/false instead of expressions, while this
would be possible in this extremely simple example, the moment you have
more conditions, you end up either writing something hard to read with lots
of && and ||, or you end up with duplicate expressions, or you can go with
returning true/false.

I don't find "return (((x && y) || a && (z || v)) && c);" to be terribly
readable. "Exploding" that into a more verbose if/else structure often ends
up making code a lot more maintainable than the 'every extra letter must be
conserved' school of thinking.

Frankly, I'm surprised that even though it should be obvious that my code
was no more supposed to be production code for a method that simple,my

"if (x) return true"

faced so much more ridicule than lipskas

"boolean var; if (x) var = true; return var",

which is basically the same only even more verbose.

Liebe Gruesse,
Joerg

 

[Eric Sosman]

[...]
Frankly, I'm surprised that even though it should be obvious that my code
was no more supposed to be production code for a method that simple,my

"if (x) return true"

faced so much more ridicule than lipskas

"boolean var; if (x) var = true; return var",

which is basically the same only even more verbose.

Perhaps you attract more ridicule because your posts have a
wider readership than lipska's. That explains my reaction, at
any rate.

`if (bool) return true; else return false;' does have one
small advantage over `return bool;' in that it's easier to
plant a breakpoint on one branch but not on the other, if a
debugging session gets down to "This shouldn't be true, should
it? *Should* it?" Similarly, the style of assigning a
`result' variable throughout the body of a method and returning
it only at the end makes it easy to trap and trace "unusual"
values. In my experience these advantages are occasionally
worth the extra clutter -- but only occasionally. YMMV.

 

[Arved Sandstrom]

[...]
Frankly, I'm surprised that even though it should be obvious that my code
was no more supposed to be production code for a method that simple,my

"if (x) return true"

faced so much more ridicule than lipskas

"boolean var; if (x) var = true; return var",

which is basically the same only even more verbose.

Perhaps you attract more ridicule because your posts have a
wider readership than lipska's. That explains my reaction, at
any rate.

`if (bool) return true; else return false;' does have one
small advantage over `return bool;' in that it's easier to
plant a breakpoint on one branch but not on the other, if a
debugging session gets down to "This shouldn't be true, should
it? *Should* it?" Similarly, the style of assigning a
`result' variable throughout the body of a method and returning
it only at the end makes it easy to trap and trace "unusual"
values. In my experience these advantages are occasionally
worth the extra clutter -- but only occasionally. YMMV.

I find the style of clearly declaring a result variable at the beginning
of a method often comes about because you have to declare the variable
anyway, because of try-catch and conditional blocks and so forth. So it
may as well get declared early.

I don't think it's a style to either decry or enthusiastically endorse.
It hardly introduces clutter, though.

AHS

 

[Stefan Ram]

`if (bool) return true; else return false;' does have one
small advantage over `return bool;' in that it's easier to
plant a breakpoint on one branch but not on the other, if a
debugging session gets down to "This shouldn't be true, should
it? *Should* it?"

It is possible to still convert »return bool;« to this »if«
should this »if« ever be needed.

http://en.wikipedia.org/wiki/You_aren't_gonna_need_it

(In fact, I'd go so far as to convert it back to the smaller
form after a debugging session needing the longer form.)

Also, one must be careful not to »convert«

if( a )then b = true;

to

b = a;

because this will change the semantics in the case of !a,
but you all know this.

 

[Arved Sandstrom]

The term, as I understand it, refers to coding under the assumption that
everyone who uses your API is a stupid idiot who can't follow your rules
properly. The matter at hand here is basically a stylistic concern about
which is mentally easier to follow, which falls under the category of
"everyone has an opinion which is strongly held and won't be changed."

[ SNIP ]

Like I stated in a different post in this thread, the stupid idiot is
often you yourself (you as in impersonal "you"), since you wrote both
the calling code and the called code, and six months later you are
adapting the called code and can't remember the assumptions you made
previously because you had a whitebox view then, and hence you f**k up.

Defensive coding actually means that stupid idiots who "can't follow
your rules properly" don't mess up the called system. This has been
fundamental software engineering since forever.

But you're right, that's not the matter at hand, since I assume that you
yourself have a healthy appreciation for defensive coding.

Style wars much? To me, personally, early-return is often valuable,
especially in languages like C++ or Java which have useful constructs
for handling post-call cleanup such as RAII or try-finally blocks. I'm
going to stop short of saying I prefer early-return, since it is very
much a decision that applies in a specific context, and these examples
are all trying to apply a universally generic rule.

[ SNIP ]

Rule of thumb - if your average coder gets how the method does exits
quickly, then your style is fine. These days - basically the last 2
decades after programming became a commodity and most coders have
minimal formal background - I'm all for coding to the LCD. Which means
very defensive, and frequently not being elegant in favour of being obvious.

AHS

 

[Daniele Futtorovic]

<snip />
See my answer to Eric, all this is just ridiculing reasonable
programming practices.

Even given Robert's example where the NPE-safe equals() is wrapped in a
method that constrains the type of object being compared to, it may not
be expected or acceptable that the String is null. So perhaps you do
want to check for that, maybe with Apache StringUtils.isBlank().

Sure, the contrived absurd examples are retarded; so is the mockery of
defensive programming. Oh well, there's a reason why most software
projects still fail or go vastly over budget.

I'm all for defensive programming, but I think that there's a limit
where it can be on the verge of silliness, and that that limit has been
grazed here.

Less-than-bright programmers IMO cannot be a justification for crossing
that line; less-than-bright programmers have more ways to mess things up
than you could possibly ever guard against. "Do not underestimate the
ingenuity of complete fools", as the saying goes.

And for me, there is an additional aspect: if a piece of code does
something simple, something basic, then I will want it to be short, and
vice-versa. Verbosity of code, to me, should hold a first-glance
indication of the complexity of the algorithm. In other words: be terse
IFF it's basic, be verbose IFF it's not.

Perhaps your mileage does vary. No beef with that. Just throwing in my
two cents.

 

[Arved Sandstrom]

On 17/06/2013 20:49, Eric Sosman allegedly wrote:
On 6/17/2013 2:32 PM, Joerg Meier wrote:
[...]
Personally, I found your example considerably harder to read than
the one
liner, as well as harder to read than what would have been my
solution:

private boolean askYesNoquestion (String str){
if(str.equals("yes"))
return true;

return false;
}

Or, for even greater clarity:

[snip drivel]

See my answer to Eric, all this is just ridiculing reasonable
programming practices.

Even given Robert's example where the NPE-safe equals() is wrapped in a
method that constrains the type of object being compared to, it may not
be expected or acceptable that the String is null. So perhaps you do
want to check for that, maybe with Apache StringUtils.isBlank().

Sure, the contrived absurd examples are retarded; so is the mockery of
defensive programming. Oh well, there's a reason why most software
projects still fail or go vastly over budget.

Have you taken a 'sensible pill' by any chance?

I find myself agreeing with you twice in the same thread ... is it me?

IME one of the main reasons for failure is the attitude of certain team
members that they are far too clever or far too important to the project
to code responsibly. Their attitude is 'gosh, look at me I'm so clever
that I can write code that only I can understand'

I once knew a PhD who's attitude to commenting code was 'I don't need
comments, I can read code'. Unfortunately this attitude carried over to
his own code which was almost completely uncommented. When asked to
comment his code his response was 'if you need comments then perhaps
you'd better find something else to do' I fired his ass

I think maybe a few of the responders to this thread could do with a
lesson in basic code readability. Of course they would never admit it,
they're obviously *way* to smart.

lipska

I don't think I took a "sensible pill".

I fairly routinely encounter uninformed programmers, or prima donna
programmers. Or simply 9-5 M-F uninterested unionized programmers who
can't lose their job even if they do nothing. Over thirty years this
covers several hundred projects, teams and clients (in-depth knowledge
of those situations even if I wasn't actually directly involved), so I
don't think my observations are completely anecdotal or without merit.

The LCD is the average guy - and these days it's still overwhelmingly
guys - who isn't all that experienced (after all, every one of us once
had just 2 or 5 or 10 years of experience), who may not be formally
trained or may be badly educated, who may not be that motivated, and who
quite often regards programming as a way to pay the bills and not as a
craft nor as a delight.

If we stick to Java, the LCD doesn't quite get the difference between
reference and equals() comparisons, and when informed still needs
coaching to write a good equals(). The LCD often has never heard of
O(n), and far from being able to choose a good sort has in fact never
heard of most of the common sorting algorithms. Same goes for search, I
run across coders all the time that have never heard of fundamental
search strategies. This average programmer doesn't read blogs or
articles, doesn't know white box or black box testing theory, knows
almost nothing about JVM tuning [1], and is very weak on concurrency. So
forth and so on.

This is what *I* see in industry, in government and large corporate IT
projects. But maybe other folks have experienced idylls of nothing but
top-notch developers, and have started to get complacent. Dunno.

I don't know why there's even an argument about this, either defensive
coding or dumbing stuff down. In the real non-academic world you've got
to do it.

AHS

 

[Robert Klemme]

I find the style of clearly declaring a result variable at the beginning
of a method often comes about because you have to declare the variable
anyway, because of try-catch and conditional blocks and so forth. So it
may as well get declared early.

I try to declare in the smallest necessary scope. And I find myself
converting

boolean result = false;
try {
result = whatEver() || somethingElse();
}
catch (whatever...) {
no return or change of result
}
return result;

to

try {
return whatEver() || somethingElse();
}
catch (whatever...) {
no return or change of result
return false;
}

because I find that more readable. Variables are not a value in itself.
If they don't serve a purpose they should go away IMHO since they
decouple calculation of the value from usage. Of course, if you need
the same value multiple times then that warrants every variable. But
cases like the one above do not.

I don't think it's a style to either decry or enthusiastically endorse.
It hardly introduces clutter, though.

Right.

Cheers

robert

 

[Lew]

Arved Sandstrom wrote:
.. . .

If we stick to Java, the LCD doesn't quite get the difference between
reference and equals() comparisons, and when informed still needs
coaching to write a good equals(). The LCD often has never heard of
O(n), and far from being able to choose a good sort has in fact never
heard of most of the common sorting algorithms. Same goes for search, I
run across coders all the time that have never heard of fundamental
search strategies. This average programmer doesn't read blogs or
articles, doesn't know white box or black box testing theory, knows
almost nothing about JVM tuning [1], and is very weak on concurrency. So
forth and so on.

The sad thing is that your observations are accurate, and mine are similar.

The thing that makes me mad is that, despite these people's job titles,
they are not computer programmers. The things you describe are elementary
programming knowledge, things taught early in the process. For anyone to
collect a paycheck for that skill not to know these things is an insult.

They should be fired.

This is the sort of thing that makes me favor making computer programming
a formal engineering discipline. No one, at all anywhere, should tolerate someone
calling themselves a computer programmer who is that ignorant, incompetent and
uncommitted to the skills of their profession, let alone pay them for it.

 

[Sven Köhler]

Am 19.06.2013 22:20, schrieb Robert Klemme:

boolean result = false;
try {
result = whatEver() || somethingElse();
}
catch (whatever...) {
no return or change of result
}

I would like to add, that I dislike the initialization of result in this
example. If result (for whatever reason) must be declared outside the
try-catch block, then please don't initialize it unless you plan on
doing something nasty. A nasty example would be that the try block sets
result to true midway and an exception in the second half doesn't change
the value of result to false for some weired reason.

The IMHO cleaner way is the following:

boolean result;
try {
result = whatEver() || somethingElse();
}
catch (whatever...) {
result = false;
}
// use result for whatever


And may all (ex-)C programmers in this group refrain from telling me
that not initializing variables is dangerous. This is Java, where the
compiler enforces initialization of variables on all code paths before
the first read-access to the variable.


Regards,
Sven

 

[Robert Klemme]

Am 19.06.2013 22:20, schrieb Robert Klemme:

I would like to add, that I dislike the initialization of result in this
example. If result (for whatever reason) must be declared outside the
try-catch block, then please don't initialize it unless you plan on
doing something nasty.

Absolutely. The reason is that by initializing the variable you forgo
the Java compiler's data flow analysis. Without initialization you will
immediately know if there is a code path which uses the variable without
prior initialization.

A nasty example would be that the try block sets
result to true midway and an exception in the second half doesn't change
the value of result to false for some weired reason.
Right.

The IMHO cleaner way is the following:

boolean result;

I'd even recommend making that variable final if possible.

try {
result = whatEver() || somethingElse();
}
catch (whatever...) {
result = false;
}
// use result for whatever

Generally I prefer not to have code after the catch block (unless it's a
finally block ) because that means that error handling is not
centralized but rather interspersed with other logic. I have seen
methods with multiple try catch blocks in them on the same level which
made them really unreadable. If that is necessary then I'd either
combine catch blocks and if that cannot be done I'd rather refactor
reasonable sections into separate methods.

And may all (ex-)C programmers in this group refrain from telling me
that not initializing variables is dangerous. This is Java, where the
compiler enforces initialization of variables on all code paths before
the first read-access to the variable.

Exactly. And another difference to C is that you can declare variables
anywhere - not just at the top of the method body. I have seen too many
Java methods which did that and used the variable 30 lines below. That
really makes reading and understanding code hard.

Cheers

robert

 

[Arved Sandstrom]

I'm all for defensive programming, but I think that there's a limit
where it can be on the verge of silliness, and that that limit has been
grazed here.

Less-than-bright programmers IMO cannot be a justification for crossing
that line; less-than-bright programmers have more ways to mess things up
than you could possibly ever guard against. "Do not underestimate the
ingenuity of complete fools", as the saying goes.

And for me, there is an additional aspect: if a piece of code does
something simple, something basic, then I will want it to be short, and
vice-versa. Verbosity of code, to me, should hold a first-glance
indication of the complexity of the algorithm. In other words: be terse
IFF it's basic, be verbose IFF it's not.

Perhaps your mileage does vary. No beef with that. Just throwing in my
two cents.

It's a good discussion. I'm not personally convinced that verbosity adds
complexity, as a rule. There's really two types of complexity here:
maintainability complexity - as in, can Joe Blow 12 months later
understand the code best if it's compact versus unrolled, and formal
complexity, cyclomatic and otherwise.

I'll admit that verbosity does usually add maintainability complexity,
if not the other kind. But not always. I've seen plenty of code that is
conceptually quite complex but very terse.

AHS

 

[Joerg Meier]

[...]

days = gdatebin(String.format("%02d/%02d/%02d",day, month, year));
return gbindate(days - 1);
}

... and wasn't much longer in assembler.

gdatebin() converted a date string into binary days since 31/12/1899 and
gbindate() did the reverse. I have no idea why the bloke thought his mess
of assembler would fall over after Feb 2100: the 1900 held dates in a
signed 24 bit number, so its Y2K moment isn't due until some time in
24866 AD.

It's ironic that after all that, your algorithm would have failed on Y2K

Liebe Gruesse,
Joerg

 

[Daniele Futtorovic]

It's a good discussion. I'm not personally convinced that verbosity adds
complexity, as a rule. There's really two types of complexity here:
maintainability complexity - as in, can Joe Blow 12 months later
understand the code best if it's compact versus unrolled, and formal
complexity, cyclomatic and otherwise.

I'll admit that verbosity does usually add maintainability complexity,
if not the other kind. But not always. I've seen plenty of code that is
conceptually quite complex but very terse.

Sorry to nitpick, but I don't think you understood me right. I'm not
saying that verbosity adds complexity; I'm saying: if the piece of code
does something tricky, something complicated, tend to make it verbose,
otherwise, tend to make it terse. Thus, seeing a big blob of (e.g.
unrolled, step-by-step) code holds the message "here be dragons". (And
if it cannot be made verbose, then it means it absolutely requires an
in-line comment).

At least the way I perceived it, this discussion was about making stuff
verbose indiscriminately, viz. basic code as well. I disagree with that
in the above sense.

 

[Joerg Meier]

[...]
days = gdatebin(String.format("%02d/%02d/%02d",day, month, year));
return gbindate(days - 1);
}
... and wasn't much longer in assembler.
gdatebin() converted a date string into binary days since 31/12/1899
and gbindate() did the reverse. I have no idea why the bloke thought
his mess of assembler would fall over after Feb 2100: the 1900 held
dates in a signed 24 bit number, so its Y2K moment isn't due until some
time in 24866 AD.

It's ironic that after all that, your algorithm would have failed on Y2K

How do you work that out?

I must apologize for prompting this long (but interesting) post based on a
mistake on my part: my sleep-deprived brain forgot about that pesky 400
year thing affecting 2000. That seems to happen a lot to my posts here
lately. In other words: my bad, I see nothing wrong (other than the +1
thing).

Liebe Gruesse,
Joerg

 

[Arved Sandstrom]

Sorry to nitpick, but I don't think you understood me right. I'm not
saying that verbosity adds complexity; I'm saying: if the piece of code
does something tricky, something complicated, tend to make it verbose,
otherwise, tend to make it terse. Thus, seeing a big blob of (e.g.
unrolled, step-by-step) code holds the message "here be dragons". (And
if it cannot be made verbose, then it means it absolutely requires an
in-line comment).

We're very much in agreement, on all points you just made.

At least the way I perceived it, this discussion was about making stuff
verbose indiscriminately, viz. basic code as well. I disagree with that
in the above sense.

I won't speak for anyone else, the argument I was making was for
verbosity in support of defensive programming. I see Java code all the
time where exceptions are try-caught with no thought placed into
handling the problem somewhere - defensive coding fail...and handling it
properly would add verbosity.

I see main methods all the time where someone assumes the number and
type of arguments. Defensive coding fail. I see methods all the time -
like I said - where the same coder wrote the calling code and called
code, and makes assumptions about what the calling code will do.
Defensive coding fail.

Or they make the naive assumption that people read Javadocs thoroughly.
It's not the calling code's responsibility to protect the called code,
after all. Given that we have to consider the bounds of parameters
carefully, I don't see how some verbosity in the form of defensive code
is objectionable.

"Here be dragons" often means simply that there is - that we have to
guard against what the calling code is doing.

AHS

 

[Arved Sandstrom]

I'm with you there.

My attitude is that well-laid out code with well-thought out names and
intelligently commented offers about the best chance of being more easily
maintainable. I prefer blocks of well formatted and carefully written
comments places ahead of what they describe to any other type.

I've certainly see some memorable examples of badly documented and over-
clever code in the past.

One of my favourite examples of bad documentation was actually quite good
code: it was just the commenting style that was naff. This was MC 6800
assembler, and the house style was to add a comment alongside every
instruction whether it needed it or not: the machine had INC and DEC
instructions to and or subtract 1 from a register, but did it really add
anything the write "BUMP THE B REGISTER" alongside every INC B
instruction?

As it happens, my worst ever example was also assembler: this time PLAN 3
assembler for an ICL 1900. In this case it was a lineprinter page, i.e.
about 60 instructions whose task was the work out the date of the last
day of the current month so it could be printed on financial statements.
it worked by doing arithmetic on the current date in "dd/mm/yy" format
This page has two comments: the first said "Calculate the last day of the
month" and the second said "Works until Feb 2100". The rest of the page
contained a mess of register-to-register operations and relative
branches. There wasn't a single label or variable name in the whole mess.
I never met anybody who could follow it past its first dozen steps - and
that includes me - and I used to be fairly good at programming in PLAN.

The silly thing was that the date calculation was trivial on a 1900,
which held dates internally as days since 31 Dec 1899 and provided a set
of date manipulation subroutines. The obvious solution, given that
library, and writing the routine in pseudo-Java in deference to this 'ere
august forum, looks like this:

public String lastDayOfMonth(String today)
{
int day = 1;
int month = today.substring(3,2);
int year = today.substring(6);
if (month > 12)
{
year++;
month = 1;
}

days = gdatebin(String.format("%02d/%02d/%02d",day, month, year));
return gbindate(days - 1);
}

... and wasn't much longer in assembler.

gdatebin() converted a date string into binary days since 31/12/1899 and
gbindate() did the reverse. I have no idea why the bloke thought his mess
of assembler would fall over after Feb 2100: the 1900 held dates in a
signed 24 bit number, so its Y2K moment isn't due until some time in
24866 AD.

And, yes, I do know my algorithm worked correctly despite leap years and
all: it ran for years as part of an accounting package and anybody could
see exactly how it worked even though it was written in COBOL.

Ahhh, dates. Just this last fall had to bypass front ends for a
mainstream financial system and get at the DB directly. No docs worth a
damn, not even a good data dictionary for the database, so I had to use
the front end programs to generate DB activity of the sort I wanted
while I ran a SQL Server profiler trace. I cleaned up the trace and
looked at the dates...what is this, I thought? Integer numbers in the
seven hundred thousands. It took a bit of sleuthing to find out that it
was rata die dates.

There is no clean way of doing rata die <-> java.util.Calendar
conversions. And that nasty little 0.5 day floating point adjustment is
a bugger. It's only now after 9 months of production that I have a warm
fuzzy about the thing being solid.

AHS

 

[Daniele Futtorovic]

We're very much in agreement, on all points you just made.

I won't speak for anyone else, the argument I was making was for
verbosity in support of defensive programming. I see Java code all the
time where exceptions are try-caught with no thought placed into
handling the problem somewhere - defensive coding fail...and handling it
properly would add verbosity.

I see main methods all the time where someone assumes the number and
type of arguments. Defensive coding fail. I see methods all the time -
like I said - where the same coder wrote the calling code and called
code, and makes assumptions about what the calling code will do.
Defensive coding fail.

Or they make the naive assumption that people read Javadocs thoroughly.
It's not the calling code's responsibility to protect the called code,
after all. Given that we have to consider the bounds of parameters
carefully, I don't see how some verbosity in the form of defensive code
is objectionable.

"Here be dragons" often means simply that there is - that we have to
guard against what the calling code is doing.

I see. Thanks for clarifying.

It looks like I had not understood the discussion about verbosity in the
same sense as you do. In my view, when talking about verbosity, we talk
about a measure on, and that's the important point, an iso-functional
basis. To illustrate, when I switch on a "verbose" flag on my command
line, I do not expect the command to perform any differently than before
-- only that it should be more talkative about it. But the functions it
performs should not be impacted by it.

To illustrate with code, and to pick some of the original examples
again, take the following two methods:

boolean method1( String input ){
return "yes".equals( input );
}

boolean method2( String input ){
final boolean ret;
if( input == null ){
ret = false;
}
else if( input.equals("yes") ){
ret = true;
}
else {
ret = false;
}

return ret;
}

This is what I mean. Both methods perform exactly the same for any
input. The only matter in which they differ is their verbosity.

And to pick up the argument again: it could be argued that the latter
form is preferable, because it is more obvious what happens in each
case. I argue against that. Not generally, but in this case. Because
what's going on there is a very basic operation (making sure the input
is exactly the String "yes"). The second form is too verbose -- that is,
so verbose that it becomes clutter. The first (non-verbose) form
expresses the intent clearly enough. If there is a "programmer" who does
not understand that (especially the null-implication), then I'm sure Lew
would have some poignant recommendations as to what avenues of
employment they rather ought to pursue, and I would happen to be in
agreement with him.

Some of what you are talking about, on the topic of defensive
programming, on the other hand, I would call functional defects. I do
not perceive those as being matters of verbosity or not, but of whether
the code is functionally complete or not. To your hypothetical
programmer who does not handle exceptions because it would supposedly
add verbosity, "verbosity" is but a pathetic front to mask either their
lack of professionalism.

The other examples you give definitely fall in the realm of defensive
programming. Yes, a method should not make hidden assumptions as to its
parameters (OTOH there would be nothing wrong per se with what I'd call
an explicit assumption along the lines of: if( argumentNotValid ) throw
new IllegalArgumentException(); ). Yes, every caller should be defensive
about what the callee might return (within the boundaries of its
contract). It should be noted that annotations have given us a potential
tool forcibly to impose more stringency in these regards, although the
way I see it it won't really be usable until teh Oracle makes the effort
to formalise them and adds them to the core lib (I mean things like
@NotNull). It still needs to mature a bit I think.

The aforementioned is mitigated in code that is internal to a component
(in the spirit of encapsulation, code ought to be divided into
components such that the density of interrelation of code within a
component is always strictly greater than that of interrelation of code
in different components). Think private or package-private methods. It
is often impractical and counter-productive to have
to forego any hidden assumptions in those parts of the code. Then again,
it is precisely the combination of these two aspects, that it is
impractical and that it would be necessary, which makes OO and esp.
encapsulation such a virtuous tool: by structuring code and data flow,
you *can* relegate, notably, input checks to the boundaries of the
component and operate on assumptions within the component. (Granted,
this does not help the case where multiple programmers who are not in
relation with each other work on the internals of the same component,
which is why such a situation should be avoided).

 

[Daniele Futtorovic]

.... and who makes these seemingly arbitrary decisions about what is and
what isn't 'complex'. This idea that some bits of code can be written
differently (more/less verbosely) depending on someones definition of
'complex' is exactly the sort of thing that makes code less readable.
Let's be quite clear about this, the *most important* thing
is readability.

Complexity is an objective measure, relative to the environment
constituted by the software as a whole, of how sensitive the process in
question is.

Anyone who has experienced 'flow' when writing code will
know that what was blindingly obvious yesterday can be arcane and obtuse
today. You need to pick a style and stick with it, not chop and change
between arbitrary styles on some whim.

I'm tempted to say that this behavior typifies the too clever by half
attitude that makes our job so frustrating sometimes but that might be
construed as confrontational so I won't ...

And who makes this arbitrary decision about what is and isn't "too
clever by half"? Cleverness is not a sin. As it were, I strive for it.
Cleverness is the path to betterment, individual as well as human as a
whole. If you aren't clever or don't want to be, that's not my problem,
but get out of my way.

 

[Daniele Futtorovic]

The aforementioned is mitigated in code that is internal to a
component (in the spirit of encapsulation, code ought to be divided
into components such that the density of interrelation of code
within a component is always strictly greater than that of
interrelation of code in different components).

You mean it should be cohesive (the code in a component), still, why
use one word when fifty will do.

as you say.

"verbosity is but a pathetic front to mask either their lack of
professionalism" [sic]

No, I did not simply say it should be cohesive. If you want to
substitute "cohesiveness" for "density of interrelation" (which is fair
enough), I said it should be more cohesive within the component than
between components, and that this is what characterises something as
being a component. Not the same thing.

But still, assuming it were the same thing for a moment (which, again,
it is not by a wide stretch), do you really think that completely
twisting my words, under the guise of quoting me, to proceed to
advocate, for a natural and hence inexact language, a practice which you
rebuke me for advocating for a computer and hence exact language is
going to induce me to take you seriously?