5 ms·

I wholeheartedly disagree. Linear functions like this promote laziness in variable naming (var a1, c_tfr, bvf, etc). This also leads to buggy side effects such

I wholeheartedly disagree. Linear functions like this promote laziness in variable naming (var a1, c_tfr, bvf, etc). This also leads to buggy side effects such as having multiple nested if statements performing a plenko-machine determination of code branching. It’s horrid. It’s unmaintainable. It guarantees that someone will have to rewrite it after your gone, because you will be gone. This is the same as someone arguing for scrolls when books with table of contents and appendices are far superior.

rramadass 3y ago
Your rant is misplaced; it is the spirit rather than the letter of the thing that matters. Linear giant code is often easier to comprehend for structures like state machines where you can follow the business logic from one stage to another easily. See my other comment here: https://news.ycombinator.com/item?id=37518275 https://news.ycombinator.com/item?id=37518275
- gabereiser 3y ago
  DRY, SOLID, there’s a wrath of principles on why this isn’t correct. Here’s what Code Complete [0] has to say… >” From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100-200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as depth of nesting, number of variables, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se. If you want to write routines longer than about 200 lines, be careful. None of the studies that reported decreased cost, decreased error rates, or both with larger routines distinguished among sizes larger than 200 lines, and you’re bound to run into an upper limit of understandability as you pass 200 lines of code.” [0] https://books.google.co.in/books?id=LpVCAwAAQBAJ&pg=PA174 https://books.google.co.in/books?id=LpVCAwAAQBAJ&pg=PA174
  - rramadass 3y ago
    These are all just guidelines/heuristics and should not be treated like inviolable laws. Thus all advice should be adapted to the problem at hand in the service of Readability/Comprehensibility first. Instead of repeating myself, i point you to my other comments in this thread for details.

rramadass 3y ago

Your rant is misplaced; it is the spirit rather than the letter of the thing that matters. Linear giant code is often easier to comprehend for structures like state machines where you can follow the business logic from one stage to another easily. See my other comment here: https://news.ycombinator.com/item?id=37518275 https://news.ycombinator.com/item?id=37518275

gabereiser 3y ago
DRY, SOLID, there’s a wrath of principles on why this isn’t correct. Here’s what Code Complete [0] has to say… >” From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100-200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as depth of nesting, number of variables, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se. If you want to write routines longer than about 200 lines, be careful. None of the studies that reported decreased cost, decreased error rates, or both with larger routines distinguished among sizes larger than 200 lines, and you’re bound to run into an upper limit of understandability as you pass 200 lines of code.” [0] https://books.google.co.in/books?id=LpVCAwAAQBAJ&pg=PA174 https://books.google.co.in/books?id=LpVCAwAAQBAJ&pg=PA174
- rramadass 3y ago
  These are all just guidelines/heuristics and should not be treated like inviolable laws. Thus all advice should be adapted to the problem at hand in the service of Readability/Comprehensibility first. Instead of repeating myself, i point you to my other comments in this thread for details.