Why do my colleagues hate it when I add an empty line of code?
Sometimes I add a few lines to see when a method ends and another one starts more easily.
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
|||||||||||||||||||||
|
|
I think most answers missed the point here. You're adding multiple lines after method scopes, right? Well that's simply not a common convention. And because it's not a common convention, it's annoying to keep noticing it while reading code. So to be less annoyed: stick to one convention. Even if that's what your teammates want and you don't. Otherwise, try to persuade them that yours is better. But either way, not sticking to one is a bad idea. |
|||||||||||||
|
|
I like Yam Marcovic's answer. But I have a contrasting view. We are often told to follow uniformity. Uniformity is often an unquestionable aspect in programming which is unfortunate. I see beauty in little individualistic things like bob's extra lines after method end, or a typical spelling mistake of a specific word in a comment by sandeep, etc. I don't force them to correct if it is really not a problem. |
|||
|
|
|
If you are only the person who is coding, it doesn't matter if you add one or ten blank lines in your code. But if you are working in a team, your code should look and feel as consistent. If you are not following conventions that your team follow, its your mistake. |
|||
|
|
|
Ease of reading and navigation are important concerns when laying out your code. Programmers will usually try to avoid excessive waste of vertical whitespace because it limits the amount of code they can see in a single view. In almost all cases you should be able to see the whole of a function or method with a single Page-up/Page-down. (Yes - factoring code out into separate functions is also important, of course). Experienced programmers in a given language can usually see the structure based on other cues than blank lines. Particularly, if you are following the indents, blank lines work against you. It's often observed that new programmers, with the best of intentions, rely more on whitespace than their more experienced counterparts. Diff'ing software can usually be configured to ignore insignificant whitespace differences, but even so, the version control issues mentioned by other commenters are real, if less important than the readability aspects. |
|||
|
|
|
The code as stored in the VCS should have (ideally) One True Style. The exact shape and nature of OTS doesn't really matter. If you want extra blank lines while you work on the code, go ahead and insert them, but make sure you undo your extra-empty-lines-ing before you submit. If at all possible, hook a "make code conform to style" filter into your check-in path. |
|||
|
|
|
how about setting up a code formatter as a hook on your SCM prior to commits. That way everyone can have their own code format preferences but when committing it all gets formatted back to the common standard. Any good modern IDE would have a code formatting system. Eclipse for example makes this very easy. Good looking code (to me) is always just a ctrl-shift-f away. |
|||
|
|
|
Empty lines can be good for structuring code, but they should be used with care. A blank lines also means that fewer lines of actual code fit on the screen. The more code you can see at the same time, the better. So, as other pointed out before, especially multiple consecutive blank lines are discouraged. |
|||
|
|
|
Probably because you're not adhering to their style convention. In coding even whitespace is important. |
||||
|
|
|
They hate it because it creates check-ins that have no value (to them), and it forces them to update before they commit. Either tell them to configure their revision control system (you are using revision control, aren't you?) so that it completely ignores differences in whitespace, or use an editor that has automatic code folding and outlining so that the number of lines between methods is irrelevant. |
||||
|
|
|
I don't think they hate that you add the newlines, but they hate it when you add it to their existing code because it will trigger a change in your SCM, the compare view will show changes even though the new lines semantically aren't doing anything. It's not really a programming mistake, but more like something slightly annoying that could be avoided. In our company we auto-format the code when we save it so the code looks the same on every machine. You might have to get used to the common style, but it's something that'll happen automatically over time. |
|||||||||||
|
