Do you use blank lines in your code?

No. I also write pre-minified code. Whitespace is for amateurs.

What's the difference between programmers.stackexchange.com and stackoverflow.com? Aren't they pretty much the same?

I don't agree with the space in the users given example. If those were each 4-5 lines of distinct functionality it makes sense but if every line gets called "distinct" and you have almost as much white space as text that's silly.

I definitely think it improves readability to break up these chunks of functionality. The problem, though, is I can't think of a good example that I don't think will have someone tell me to put them in two different methods...

I think that's like asking if you use salt when you cook. I can't imagine how you'd get things done any other way.

Here's a quick & dirty Java class file parser I have open in the other window, a representative sample of how I work. I can't imagine how such a thing could be written legibly liberal use of blank lines.

    sub parse_class_file {
      my($fn) = @_;

      my ($name, $super);
      # my $interfaces = [];  # Not used yet

      my $constant_pool = [];
      my $fields = {};  # Referenced by name
      my $methods = {}; # Referenced by name_description

      open(C, "$fn") or die("Could not open '$fn': $!\n");

      # Cafebabe
      my $magic = read_field(\*C, "H*", 4);

      # Class file format version
      my $minor = read_field(\*C, "n");
      my $major = read_field(\*C, "n");

      # Load constant pool
      load_constant_pool(\*C, $constant_pool);

      # Class name, inheritance
      my $access_flags = read_field(\*C, "n");
      my $this_class_index = read_field(\*C, "n");
      my $super_class_index = read_field(\*C, "n");

      # Load interfaces -- just throw them away for right now
      my $interface_count = read_field(\*C, "n");
      for(my $i = 0; $i < $interface_count; $i++) { read_field(\*C, "n"); }

      load_fields(\*C, $fields, $constant_pool);

      load_methods(\*C, $methods, $constant_pool);

      close(C);

      return( { name => $constant_pool->[$this_class_index]->{name},
               super => $constant_pool->[$super_class_index]->{name},
               fields => $fields,
               methods => $methods } );
    }

I code like this. It is easier to identify code structure.

  for (int i; i < 10; ++i) {
    if (i % 3 == 0) {
      continue;
    }
    array[i] += 2;
  }

I use blank lines to separate declaration and other codes, and logical block within a function, and also between functions.

It is no use for me to put blank lines between statements. It would better to view structure in one screen. Scrolling between pages make me tired too.

Yes I use blank lines.

On a related note though, there's a lot of code in my current work project, and my previous one, where people separate every function definition with a comment line like

//==========================================================

Some files even have two lines like that between every function. It drives me nuts, in a minor way. I don't feel like I've ever had a problem seeing where functions begin and end, so I don't understand the point of those comments.

We have a coding standard document, and there's nothing in there about doing this, yet there are several slightly different styles of it than people seem to have picked up independently. Is this a game industry quirk? Is it common elsewhere? When did it start, and WHY?

Emacs can be set up (with Cedet) to draw lines between functions without any comments needed (so no wasted space either). I've had that on before too just to see if it changed my mind, but no, I don't like that either. But at least if everyone's IDE would do that, it could be a personal preference.

Inside of my JavaScript functions I use a blank line to separate my declarations (var) from the body and then my body from the return.

In my CSS and javascript, I use a couple blank lines to separate major sections of my sites, and a single blank line to separate widgets in a section, so that when I'm quickly scrolling through code, I can tell when I'm going from one widget or section to the next. In my HTML, I only put blank lines between major sections, and use comments like "end of superwidget area" to denote the ends of complex widget areas.

So when the code has an apparent structure, like the nested divs of HTML, I figure the lines are superfluous, as the fine structure is somewhat obvious, and I help myself with comments where it gets hairy. When the code is a big pile of CSS or javascript, without the obvious structure of HTML, a good spacing system really helps me keep tabs on where I am and quickly scroll to the section I'm looking for.

Of course. But I never grew up in the days of ttys or 80x25. By the time I started using unix, Linux and FreeBSD had framebuffers and even on the console I had something like 132x43.

I did edit some HTML with edit.com in DOS but I switched to notepad after a couple of months.

Maybe. To visually divide sections,

- between groups of member variable declarations if any

- between function definitions if defining more than one

- after local variable definitions if any

- before a big ugly comment and probably within the big ugly comment, but the big ugly comment needs to be removed eventually, so no.

- and finally, before the ANSI "return 0;" in main

    int i;
    
    for (i; i < 10; ++i) {
        if (i % 3)
            array[i] += 2;
    }

http://hoop-la.ca/software/cat/cat.c

I take advantage of Python's docstrings to describe what the following code does to the point where I don't feel the need to add blank lines within a function. It's all explained upfront, which seems to improve the readability of the compacted code. This habit has spilled over to other languages with no implicit structure so that code is organized between descriptive comment blocks. This has been really helpful with markup languages like PHP or Coldfusion, where indentation is meaningless and often negatively affects the quality of the outputted code.

Once I outgrew QuickBasic in junior high, I started developing in C in DOS, using RHIDE (it came with DJGPP). RHIDE supported advanced VGA text modes like 128x43, so I've always used blank lines and wide lines when their use made code clearer.

I once had to do maintenance on a Visual Basic project with zero blank lines and minimal comments "to save screen space," even though the developers had decent-sized LCDs.

In theory, if I start feeling the need to break up a function body into logical blocks, it's time to refactor, so no, whitespace is not used except to keep functions apart from each other. In practice though, I probably dump everything in main() more often than not, so yeah, whitespace is used.

Most programming languages ignore blank lines. One notable exception is Whitespace (https://secure.wikimedia.org/wikipedia/en/wiki/Whitespace_(p...

I'll use blank lines if there is nothing else, but I tend to find that when you need to use blank lines to delineate function that a refactoring is in order.

The example

  for (int i; i < 10; ++i)
  {
    if (i % 3 == 0) continue;

    array[i] += 2;
  }

Could be rewritten as:

  for (int i; i < 10; ++i)
  {
    if (i % 3 != 0){
      array[i] += 2;
    }
  }

I use blank lines in my code if that's the standard where I work. If not, I grin and bear it. No point in going against whatever style predominates at a given office. But I'm always amazed when I see (often young) programmers trying to cram as much code as they can into a small space, as if the density of text makes it all the more impressive.