Take the 2-minute tour ×
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.

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.

share|improve this question
67  
Have you asked your colleagues? –  Kevin D Nov 17 '11 at 9:23
46  
Commence existential discussion about whether an empty line is a line "of code". –  Rein Henrichs Nov 17 '11 at 9:40
1  
@Jeremy Here's a simple one one: $(svn blame FILE | awk '{print $2}' | sort | uniq -c) –  Izkata Nov 17 '11 at 14:57
2  
Hate it? Is it possible you work in a Whitespace shop? –  Yannis Rizos Nov 17 '11 at 18:05
4  
​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​ –  Jarrod Roberson Nov 17 '11 at 18:25

10 Answers 10

up vote 75 down vote accepted

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.

share|improve this answer
23  
+1 for stick to one convention. OP: Stop being a special snowflake; you don't own those files the project does. –  Jeremy Nov 17 '11 at 14:26
2  
I wish I had time to focus on blank lines. Consistency is good but who cares? Tell them to take a pill. –  JeffO Nov 18 '11 at 4:16
    
2 lines after a function is standard in Python, but Python doesn't have the ending } that some other languages do. –  Brendan Long Nov 18 '11 at 6:11
    
@JeffO First of all, you have time. It just mightn't be a habit. Either way, if you think it's good, then you can make it a habit or better - script it. –  Yam Marcovic Nov 18 '11 at 17:58

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Probably because you're not adhering to their style convention. In coding even whitespace is important.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
13  
If that's really the case (fairly possible) ALL major SCM's have an option to ignore whitespace diffs during a merge. –  Yannis Rizos Nov 17 '11 at 9:42
3  
@YannisRizos doesn't matter, it still shows up as a change on a diff, and thus will trigger things like code review cycles, which take a lot of time. –  jwenting Nov 17 '11 at 11:29
    
Yes, but op described what his coworkers feel as hate instead of annoyance, so I immediately though of merging... :) –  Yannis Rizos Nov 17 '11 at 11:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.