|
Kent Sharkey wrote: very, very frightening me!
Galileoooo, galileooo, Galileoooo, galileooo, Galileoooo Figaroooo
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Beelzebub has a devil for a sideboard. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
C# is a very flexible language, allowing you to write clean and functional code, but also very bloated code. Readability is overrated?
|
|
|
|
|
When I look at that web page, I find myself thinking "wow, that page could REALLY BENEFIT FROM HAVING A SCROLLBAR"! 
|
|
|
|
|
Kent Sharkey wrote: Readability is overrated?
Obviously. The shorter you can write some code, the smarter you are.
That guy complaining that reading it takes too long just proves his incompetence.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
|
I never understood how putting braces on a separate line "improves readability". Imagine a fiction text, a short story or novel, where each comma, semicolon or full stop is put on a line by itself: Would that improve readability?
To me: Certainly not. 30-40 years ago, technical documentation was ridden by a wave of "Structured writing": Everything should be a bullet point, a paragraph, a chapter in an n-level structure (with no limit on n - I saw one manual of thirteen chapter levels!), or whatever. Anything but "unstructured text" - a two-paragraph sentence was a sign of missing structure. The structure was the essential thing. I had a feeling that contents was somewhere between inessential and absent. Fortunately, the most extreme "structured writing" ideas faded away.
If a programmer does not have the mental capacity to process both a premise and a conclusion as a whole, as one unit, but demand a format that says, e.g.
- We are deviating from a linear sequence of actions: This is a break of flow, so we will prepare you for it by adding a blank line before this break.
- We are going to chekck out something, so look out: Here is an 'if'
- Even though you now know we will test something, we add puctuation to tell you where the condition starts: an opening parenthesis.
- Now comes the condition: age < 12
- To make sure that you understand that we are done with the condition, we have added a closing parentheses.
- Even though we are done with the condition and ready to go on with the action, we have added an opening brace so that there is no doubt that the action starts here.
- To make sure that you don't overlook the fact that this is a conditional action, we put that brace on a new line.
- On the next line, we have stated the action: charge = child_fare
- To make sure that you understand which actions are conditional, we have indented those statements by four positions.
- To make sure that you see that this is one complete action, we have added a semicolon at the end.
- To make sure that you see that this is the end of all conditional actions, we have marked it with a closing brace.
- To make sure that you don't overlook that this is the end of the conditional actions, we have put the closing brace on a line by itself.
- To make sure that you don't overlook that we now return to actions that are unconditionally executed, we set it off by a blank line.
All of this is explicitly expressed when code goes like (C style):
[blank line]
if (age < 12)
{
charge = childfare;
}
[blank line]rather than (Pascal style):
if age < 1 then charge = childfare; Pascal does require the 'then' keyword, but the closing semicolon may be superfluous, needed only if what follows is a block. (A single statement is a block.)
Lots of C programmers insist that adding a lot of non-action syntactic elements, such as parentheses, braces, blank lines, ..., although they provide no problem/action specific information, they are essential for understanding problem or solution actions. We do mentally process the entire list of "decorations" quoted above to gain this understanding. I am not claiming that costs a lot of effort, but it is there.
I see it as a reminiscence of the 'structured writing' idea, of 'structure before conents'. Obviously you e.g. indicate (usually by indenting) a set of conditional actions. If (the language designers wasn't capable of handling a single action as a block, so you must add braces around it, or or require you to put parentheses around a condition), you must of course {do that}. But I do !confuse syntactical workarounds with readability!
I know from experience that it helps to double space my code when showing it to others. Even if the opening brace is at the end of the line above, that is inessential - the other person may even overlook that there is a completely blank line before, say, the loop body (rather than a brace line). He may overlook that there are blank lines between every statement: Some people put blank lines around every "structured" statement, such as if-statements, so the difference from double-spacing is minimal.
You might argue that doublespacing improves readability indeed. Then, leave it to the display or print function! When you work on a method of 30-40 statements, you should be able to see all on the screen, without having to scroll up and down over three screenfuls!
|
|
|
|
|
You're comparing code to a book that you read. It's not read in that way.
I'm not going to argue; just learn C++.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
There was actually a study a number of years ago where a large panel of softare developers were randomly split into to grops: One half was given the source code of a program in a layout inspired by the way you write prose text, as a narrative. The other half got it as we (read: C programmer) usually lay out code, e.g. wiht premise and conclusion split on two lines, with a brace opening line inbetween. The source code, in the sense: the sequence of tokens, was identical, only the layout was different.
The two groups were given the same amount of time to make themselves familiar with the program code. Then they went through an extensive questionnarie to judge how well they had understood the workings of the program. The results showed that those programmers who had read the prose-inspired layout of the source code scored significantly higher, they had a better understanding of the program.
I'm not going to argue; just learn C++. When did I learn C++? We obtained an early pre-release that compiled not to binary code but to K&R C, so we got a chance to see how classes were represented, with the method tables etc. How object instances were linked to the class object. How subclasses were implmented. An interesting learning experience! This was at the end of my studies, which were completed in 1983, and I am somewhat surprised that the first official C++ release was not until 1985. So I guess I have known C++ since it was a fetus.
Someone said that "Unix is user friendly, it is just a little picky about who it accepts as friends". You could say the same about C++. And then I could say like Peter Schieckele remarked: Well, I've got a new set of friends now ...
|
|
|
|
|
Member 7989122 wrote: The results showed that those programmers who had read the prose-inspired layout of the source code scored significantly higher, they had a better understanding of the program.
Because they had to read the entire thing and build a model in their head; try that in a large brownfield application instead of regular debugging.
Member 7989122 wrote: Someone said that "Unix is user friendly
In a similar way that I am friendly. Most people have a different concept of the word.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Because they had to read the entire thing and build a model in their head
OK, if you think that understanding how the program works is undesirable (or impossible), and believe that something gets better by tripling the line count in the source file by adding lots of blank lines, putting braces and parentheses and maybe even semicolons on separate lines... If that is your taste, feel free too do so. Even if I dive into some huge system where I don't have a chance in a million to understand the entire code, the very least you could expect is that I understand a single method/function, and hopefully an entire module or even subsystem. If a more "prosaic" layout helps me grasp the logic, I am happy with that, even when I do not understand the entire system.
|
|
|
|
|
Member 7989122 wrote: OK, if you think that understanding how the program works is undesirable (or impossible),
I didn't say that.
You don't need to read the entire book, if the compiler points to a certain chapter. It is ineffective.
Member 7989122 wrote: If that is your taste
That's not taste, but science. People are good at spotting patterns and seeing deviations. SOLID also means we do not have to read the entire codebase to explain why the logger blew up.
Member 7989122 wrote: If a more "prosaic" layout helps me grasp the logic, I am happy with that, even when I do not understand the entire system.
"More prosaic" means using more chars to convey the same information, which is what you were advising against.
Yes, that was a set up, and an easy one. Call back if you know what you want; but if I see a blot of spaghetti in SourceSafe I will simply delete it.
..and yes, I'm being "friendly", in a Unix-way.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: but if I see a blot of spaghetti in SourceSafe I will simply delete it.
If you "see a bowl of spaghetti" just because a programmer doesn't spend one line on an opening brace (alone) and another line on the closing brace (alone), and maybe a completely blank line before and after the if-statement, then it sounds as if you are really hungry for spaghetti!
Maybe I will start using the term "homeopathic code" for that kind where only a single token carrying any information specific to the problem solution, per screenful (with the rest being blank lines, opening and closing braces and all sorts of decorations) 
|
|
|
|
|
Member 7989122 wrote: If you "see a bowl of spaghetti" just because a programmer doesn't spend one line on an opening brace (alone) and another line on the closing brace (alone), and maybe a completely blank line before and after the if-statement, then it sounds as if you are really hungry for spaghetti!
Takes a bit more than that, like "proza".
Member 7989122 wrote: Maybe I will start using the term "homeopathic code" for that kind where only a single token carrying any information specific to the problem solution, per screenful (with the rest being blank lines, opening and closing braces and all sorts of decorations)
Kinda anal on the bracket-whitespace for a single-line statement there. I don't care about that particalur example; it is being enforced because someone said it was a best-practice to have a codeblock around single-line statements.
"if (bar)
{
foo
}"
vs
"if (bar) foo)" is not worth the money, nor my time.
I once worked for someone who demanded no-one formatting their SQL, and to put the entire statement in a single line (without CR/LF). He read the SQL statement aloud while scrolling to the right. Some bugs are very visible if you apply a minimum of formatting.
Keep it up, I'm reloading.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Member 7989122 said: I never understood how putting braces on a separate line "improves readability".
Then you should like my articles!   It took a few years to come to the same conclusion.
|
|
|
|
|
About readability... I can give you that.
But I have spent a lot of time in my life trying to find errors of execution that were caused by a line of code that was supposed to be in an inlined if without brackets.
I came to the conclusion, than putting the brackets in the very first time, it might spare you a lot of time searching for it.
Member 7989122 wrote: All of this is explicitly expressed when code goes like (C style):
[blank line]
if (age < 12)
{
charge = childfare;
some = other;
}
[blank line]rather than (Pascal style):
if age < 1 then charge = childfare; some = other;
or even better:
Member 7989122 wrote: All of this is explicitly expressed when code goes like (C style):
[blank line]
if (age < 12)
{
some = other;
charge = childfare;
}
[blank line]rather than (Pascal style):
if age < 1 then some = other; charge = childfare;
Have fun searching in a big program.
if (age < 12)
some = other;
charge = childfare;
You eyes would go over this several times without realizing it is incorrect.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
E.g. the Coverity analyzer pinpoints such problem as those you point out. (But you have to do the reformatting yourself)
In any case: If you have a code formatter that enforces code layout according to a complete set of rigid rules, then it doesn't matter if the coder writes the code in the way you indicate - the formatter will fix it.
If the formatter does not enforce a rigid set of rules, or if the rule set is incomplete, then there will always be ways in which the coder could mess up things.
So we are talking about either which rules should a formatter enforce, or which rules should the coders write theuir code by. When I am not under the control of some other coding style, among the rules I follow are
* You never have an indent without a bracing construct (which one is language dependent)
* You never have a bracing construct without an indentation.
* You never have a statement separator (such as a semicolon) anywhere but at the end of a line.
* If the body of a structured statement (such as an if) is a single statement (and need no bracketing) and it fits within a line lenght of 80, they it might be accepted on the same line. Otherwise, and it is moved to the next line, it must be indented and braced (according to the first rule).
Having programmed by these rules for thirty years, it would take me a lot of pain to break them. I would never accept it in code that I am responsible for.
|
|
|
|
|
Another guy that can't write code, yet he feels qualified to tell everybody else how it should be done.
I put that as succinctly as I could.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You make it sound as if "writing code" is dominated by blank lines, possibly with a single brace, and statements of at most 40 char length.
If he "feels qualified to tell everybody else how it should be done", how is that with you? Maybe the difference is that you are qualified to do so?
|
|
|
|
|
Member 7989122 wrote: You make it sound as if "writing code" is dominated by blank lines, possibly with a single brace, and statements of at most 40 char length.
You can put all the comments and blank lines in the code that you want, braces on their own lines, and limit lines to any length you like. The compiler optimizes out anything it can't use, and even optimizes "bloated code" to a point. If you didn't already know that, then maybe you should be writing articles to tell us how to code, as well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: The compiler optimizes out anything it can't use, and even optimizes "bloated code" to a point.
I am certainly not worried about how readable the code is to the compiler. I am worried about the humans. Arguing that "the compiler can handle bloated code, so let me write bloated code" doesn't fit well with my ideas about good coding practice.
I actually agree a lot with the author of the referenced article. I have one major point of disagreement: A code indent is triggered by a brace, or similar construct in other languages (e.g. begin-end keywords). A brace (etc.) triggers an indent. The author suggests newline/indent for single statement condition/loop bodies without using braces, that causes me to stall, just as much as I would have if people were using braces without indenting (but that never happens).
Aside from that, I essentially agree with him.
|
|
|
|
|
Other things being equal, readability is a desirable end.
A lot of the time LINQ and other functional approaches can make code more readable. But sometimes you're better off doing it the long way. I've often gone for a LINQ solution and then decided that the readability suffers and then backed out.
But sometimes you reach a sweet spot where your succinct code is simultaneously more concise, more expressive, more readable and more robust.
Kevin
|
|
|
|
|
Astronomers have produced a remarkable new image of Jupiter, tracing the glowing regions of warmth that lurk beneath the gas giant's cloud tops. "In place of a Dark Lord, you would have a Queen! Not dark, but beautiful and terrible as the Dawn!"
|
|
|
|
|
Kent Sharkey wrote: "In place of a Dark Lord, you would have a Queen! Not dark, but beautiful and terrible as the Dawn!"
My treassssure...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
In an update to its driver shiproom schedule, Microsoft has blocked out May 26-28 as a Feature Update timeframe. Just in case you want to (temporarily) disable Windows Update
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
