|
Your first example has one great advantage: When your productivity is measured in number of code lines produced, it wins by a large margin.
The disadvantage is that to get an overview over even a fairly trivial function that really should fit in a screenful, you have to flip back and forth though a pile of pages. In any sufficiently fancy editor you can split the window so you can correlate various parts of the function logic, but then you can fit half as much logic in each tile, and that may be too little!
A second disadvantage: With all that whitespace (frequently, programmers add at least one blank line before and after every loop, after function initialization, ... everywhere!), you have to look really close to see where this function ends and the next function starts. Except that those blank line lovers usually also add a huge comment block before every function to explain that ThePriceOfApplesPerKilogram argument is the price of apples per kilogram, that pi has the value of 3.1415926535897932384626433 and similar essential information.
To some of these programmers, "readability" is a synonym for "whitespace percentage". Sort of homeopathic programming: The more diluted, the more powerful.
On the other hand: The APL ideal of "There is no programming task so complex that it cannot be solved in a single line of APL" goes too far for my taste. An example from Wikipedia -The game of Life:
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
I put most regex in the same category. Geek & Poke: Yesterday's regex[^]
I'd like to place myself in the middle of the road, but I cannot deny that those homeopatic programmers raises such protests in me that I lean somewhat over to the other side. If you cannot fit every function in its entirety on a single screenful, then you have used too much whitespace.
|
|
|
|
|
This is the first time I have seen "this" being used to prefix a parameter, and Googling doesn't find it. Could you explain, please?
|
|
|
|
|
|
|
Paragraph level.
Are you thinking that the compiler does something more optimized because you wrote it as a sentence instead of paragraph? Or were you thinking that less typing benefits the project overall? Or perhaps some other underlying reason?
Paragraph style is not only more readable and understandable to another programmer reading it for the first time, it is more readable and understandable to you 6 months, a year, or 2 years later when you revisit the code for the first time since you finished it.
Paragraph style is also easier to debug and see runtime values.
When you are not the only programmer involved now or conceivably in the future, paragraph style would have a positive effect on the maintenance portion of lifecycle cost.
Another benefit of paragraph style is that it lends itself better to adding comments that explain the what and why of what you are doing.
modified 1-Jun-18 10:53am.
|
|
|
|
|
When I started I was actually thinking more about separating concepts and mechanics, or maybe better, business vs technology. But I think I lost that some when playing with creating my examples. )
In business applications (vs scientific/engineering) most methods implement some part of a business function.
At an absurdum extreme you could write the application in one procedural block with thousands of lines of branching/conditional code, where each line does no more than a single thing. It contains an atomic concept. So, you wouldn't write if(x == 1 || x == 3), that is two concepts. At this extreme, every atomic thought is crystal clear, but the big-picture of what the method does becomes a forest-trees thing.
We decompose software into logical, understandably named chunks, like methods and classes. At another absurd extreme, we could make each concept a method - bool IsValueEqualToOne(int x) {if x ==1 return true else return false}. This is just as bad. We have only translated from a technical representation (x == 1)? to a business representation IsValueEqualToOne.
In real-world programming we balance the size and form of our chunks. In some cases, it is better to combine at a "technical" level - `if(x == 1 || x == 3)`. In others, a business level is better
if(AccountHasFunds(sourceAccount, amount)){
debit(sourceAccount, amount);
credit(targetAccount amount);
}
At the opposite extreme or "can't see the forest for the trees" is "needle in a haystack", one liners. Like the examples I gave. ( and tried to disclaim as how I would actually do it.  )
So, to your question Quote: compiler does something more optimized... Or perhaps some other underlying reason?
In rereading it sounds like I may be advocating "one-liners", but not really. All the LINQ and stuff has a greater chance of compiler confusion than optimization. Maybe the best I can think of is that each method we write contains a business purpose and a technical implementation. The clearest code communicates both, and the best code does this in a maintainable way.
With LINQ style and functional becoming popular I was curious to see if people were writing more that way.
My preferred method of coding combines approaches, made easier with local functions. (I just make up "transaction syntax for simplicity)
void TransferFunds(source, target, amount){
if(AccountHasFunds(sourceAccount, amount)){
transaction {
debit(sourceAccount, amount);
credit(targetAccount amount);
}
success: {}
rollback: {}
} else { CancelTransfer(); }
[Description("Validates account balance equals or exceeds amount")]
bool AccountHasFunds(string account, decimal amount){
var accountBalance = account.GetBalance();
if ( accountBalance >= amount){
return true;
else {
return false;
}
}
[Description("Debits amount from account")]
void Credit(…){
…
}
...
}
|
|
|
|
|
In my first university level programming course (I had been fiddeling a little around before that), the professor provided one guideline that I still think is great: A program should fit in a single page. Usually, it will be more than half a page, but never more than that. ("One page" was understood to be 60 code lines.)
You can't solve the program in 60 lines of Pascal, you say? OK, so make up another programming language in which you can solve the problem in 60 lines. Say, if an essential part of your solution is to sort a table of records backwards on the surname field, according to Swedish alphabetic sorting, then pretend that you have a language in which "sorting a table backwards on the surname field according to Swedish sorting rules" is a language primitive. When you have made a clean, readable solution in this hypothetical language, you go ahead to make another program by the same basic rules: One for doing that sorting...
I think this is a very good philosophical approach to code modularization: Make yourself a language that lets you solve the problem in 30-60 lines. Less than 30 lines provides so little detail that it is useless (like "void main(void) {solvetheproblem();}"). Make sure that the way the problem is solved is visible in the code! But don't bring in too many details; requiring more than 60 distinct operations (aka. code lines) indicates that you did not use the right language for the task. So make yourself a better suited language.
Obviously, these are main rules, not absolute. Some problems require less than 30 lines, and in any production setting you cannot expect library functions to suit your problem ideally, adding red tape. But as a way of thinking, it is a great approach: Every level of your code should add a significant, but not an excessive amount of detail. And, relate that stepwise detailing to the problem at hand, not to the libraries you use, language or other coding elements.
Even today I think this lesson, in my very first year of study to become a programmer, is one of the most valuable ones I has throughout my studies.
|
|
|
|
|
In our world, and our code reviews, this one line stuff has to go.
The coding standards should dictate the formatting.
BUT: The Situation can dictate exceptions. We have defensible and in-defensible deviations.
Blocks of similar code where reading one line is effectively the same in the block, we allow
the one line to create a "tabular" view of what is transpiring.
BTW, I don't consider breaking down the code into properly formatted statements to be dumbing down the code. I also think that different companies CAN AND SHOULD have different coding standards!
But overall, I believe if you can pick up a piece of code, and not know if YOU wrote it, or someone else on your team wrote it... Then you are cooking with gas.
|
|
|
|
|
Quote: string Foo(int x){
if (x == 1) {
return "one";
} else {
return "not one";
}
}
string Foo(int x) { return x == 1 ? "one" : "not one"; }
(I also tend to twitch when I see a "return" followed by an "else".)
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 1-Jun-18 12:10pm.
|
|
|
|
|
I've seen a lot of discussion lately about single point of exit vs multiple points of exit. Since my IDE makes them easy to spot I've started using multiples more in if and switch. But when I see the code in a plain text editor it still can look a little confusing.
|
|
|
|
|
I have no issue with "multiple exits"; when used to avoid lengthy "if ... else".
The point is, the "else" in "if ... return else" is totally redunant.
And sometimes, it's "clearer" to simply return with a simple "if NOT ... return" instead of a lengthy "positive" if.
But "if NOT's" can get confusing if misused.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Got it. See what you are saying.
|
|
|
|
|
And sometimes I do:
if (... ) {
} else {
return;
}
to avoid a confusing "if NOT" or a lengthy "code block".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I frequently use multiple exits, to simplify the code structure, reducing nesting levels.
However, the last bug I fixed in one program that is my responsibility was related to this: A few months ago, I added a "try / catch / finally" to improve error handling. Within that "try" was an age old "return" for a rather curious case, hit only if the PC did not have a sufficiently updatet dotNet (and since updates are pushed from a central deployment server, this only happens if you plug in a portable that is not yet detected by the deployment server). Before the "return" was executed, the "finally" block was processed, which was certainly not appropriate in that situation.
I will certainly not stop sprinkling my code with return statements, but I have learned a lesson about paying attention to finally-clauses.
|
|
|
|
|
If God wanted us to program in sentences, He would have abolished all languages except APL. 
|
|
|
|
|
Would you call an Italian hooker a pasta-tute?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
gonna open a whole cannelloni of worms with innuendo like that
This internet thing is amazing! Letting people use it: worst idea ever!
|
|
|
|
|
Hur! Hur! Hur! He said "in your end-o"!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Only if she gave me an offer I couldn't refuse... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
Only because I'm not entirely sure how to pronounce his surname[^]. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Of course you would, fusilli guy.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
puttanesca anyone?
|
|
|
|
|
With a little broth'll be nice
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
If she Lasagna for a fee, then I'd say so. Sounds like a pretty ziti profession, orzo one would think.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Would you call an easy Mexican chick a frijol? 
"Go forth into the source" - Neal Morse
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
