Timeline for Is fewer lines of code always better?
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 15, 2022 at 21:53 | comment | added | Steve Gon | It is absolutely ableist to say that the first is harder to read. Completely subjective as well. You can't remember that both commas and line feeds can separate variable definitions? As someone with poor eyesight, I cannot read code on a page that is off screen, that is literally impossible. The first example accommodates both people with good and poor eyesight. | |
| Oct 13, 2013 at 12:33 | comment | added | mikebabcock | Neither example is easy to read. Something "real" would be nice. Consider pastebin.com/BbttaD4R | |
| Jul 16, 2013 at 18:08 | history | edited | Chris Throup | CC BY-SA 3.0 | Removed duplicate "programmers" |
| Jul 12, 2013 at 15:37 | history | edited | Tulains Córdova | CC BY-SA 3.0 | added link |
| Jul 8, 2013 at 18:15 | history | edited | Tulains Córdova | CC BY-SA 3.0 | added 4 characters in body |
| Jul 8, 2013 at 14:13 | history | edited | Tulains Córdova | CC BY-SA 3.0 | deleted 106 characters in body |
| Jul 8, 2013 at 14:08 | history | edited | Tulains Córdova | CC BY-SA 3.0 | deleted 34 characters in body |
| Jul 8, 2013 at 3:10 | history | edited | kojiro | CC BY-SA 3.0 | Correct and cite quote; qualify statement about programmers finding the second example easier to read |
| S Jul 5, 2013 at 12:07 | history | suggested | TobiMcNamobi | CC BY-SA 3.0 | Readability is paramount |
| Jul 5, 2013 at 11:12 | review | Suggested edits | |||
| S Jul 5, 2013 at 12:07 | |||||
| Jul 5, 2013 at 4:34 | comment | added | user53141 | The thing about the number of lines of code being "bad" is that long blocks of code are often caused by code repetition, which is always bad. In the questioner's example, this is clearly not an issue, but it is good to look at files/classes/functions with many lines of code as a "bad code smell", and an indication that you should look for repetition. | |
| Jul 4, 2013 at 19:55 | comment | added | Tulains Córdova | @Plankalkül Remember ease of debugging that you get with intermediate values. That's important. Will you sacrifice that for what ? But you can do it the other way as long as it is legible and elegant. | |
| Jul 4, 2013 at 19:43 | history | made wiki | Post Made Community Wiki by user541686 | ||
| Jul 4, 2013 at 19:36 | comment | added | Plankalkül | @user61852: If all you really do is putting result in front of the function name I would argue that the additional lines actually are useless because what it is will be apparent just by the method name. | |
| Jul 4, 2013 at 16:06 | comment | added | Tulains Córdova | @dodgethesteamroller LOL | |
| Jul 4, 2013 at 16:05 | comment | added | Tulains Córdova | @Plankalkül The function already has a name, as well as the parameters it receives... so you don't have to really invent much when naming the variables. | |
| Jul 4, 2013 at 15:53 | comment | added | dodgethesteamroller | Not if your manager is judging your productivity by how many lines you write per day! (Some still do, sadly...) | |
| Jul 4, 2013 at 15:47 | comment | added | Plankalkül | Well but the names are the central thing here. Start from [c = (ab) + a]. [d=ab, c=d+a] is not more readable. [tax=a*b, c = tax + a] is more readable. So if you can give the variable a meaningful name it can make sense to give it it's own line. If you have to invent a name where nobody knows what it actually represents you should just not introduce a new variable for that because what's the point in that case? | |
| Jul 4, 2013 at 14:38 | comment | added | Mike Bryant | this is just an example (not a great one I admit) to get my question across, the variable names shouldn't be taken in to account seeing as they are subject to each developer's naming convention | |
| Jul 4, 2013 at 14:25 | comment | added | Plankalkül | In that specific example the first version is clearly more readable. Since the names of the variables don't give any additional information more lines just means that you have to search for the meaning of the parameters. But yes: In general more lines are often more readable. | |
| Jul 4, 2013 at 13:48 | vote | accept | Mike Bryant | ||
| Jul 4, 2013 at 12:29 | comment | added | Tulains Córdova | @JoachimSauer of course, as I said, the important thing is not number of lines. | |
| Jul 4, 2013 at 12:24 | comment | added | Joachim Sauer | +1, but be careful: more lines of code aren't always better either! | |
| Jul 4, 2013 at 11:55 | history | edited | Tulains Córdova | CC BY-SA 3.0 | edited body |
| Jul 4, 2013 at 11:37 | history | edited | Tulains Córdova | CC BY-SA 3.0 | added 52 characters in body |
| Jul 4, 2013 at 11:32 | history | answered | Tulains Córdova | CC BY-SA 3.0 |