Lol, yeah only kidding - I don't write minified code. No, I just skip that layer entirely and type pure gzipped data.
edit: but seriously, yeah I use tonnes of whitespace and bucketloads of comments. No point making things harder than they need to be. Also commenting helps you solidify your understanding of the code.
I tend to write like this:
while(foo) {
code;
}
rather than
while(foo)
{
code;
}
I use newlines to separate tasks in the code. Example:
// do the foo check
if(foo){
removeFoo();
}
// now perform the bar operation
if(shouldDoBar) {
performBar();
}
// now return
return fooBar;
Programmers.SE is intended for questions programmers have that are only indirectly related to programming. It allows many things that would be considered off-topic on stackoverflow.com.
I find the "stackoverflow" style app to work pretty well regarding getting and finding answers, but it seems like Jeff/Joel don't trust it to work when they break things out into all these other sites like this one. Do people really just browse these type sites? And even if they do, doesn't tagging solve most of that?
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...
Maybe different philosophies apply to newer languages, but I've heard it said that in C your main functions should be more than just a list of function calls, and a function should only be extracted if it's either impossible to read otherwise, or used more than once. Maybe that's less important now that function call overhead is minimal compared to everything else.
I will note, however, that function call overhead still adds up. Qt4 on GNOME is significantly slower delivering events than it needs to be, as every single call stack is over 50 methods deep.
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 } );
}
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.
I know what you're talking about pretty well (I used a macro to generate those things). I always figured it was a trace of a more rigorous documentary scheme used for automatically generating scripting documentation or something. Like once you get used to seeing them, you want them between every function, or if you start writing a function you always start with the hedgerows. Not sure.
I hadn't seen those specifically at other developers, but I had seen a row of slashes between functions at a couple of other PC developers. I don't recall seeing them with console folks, though.
My background and current project are PC-centric, but there are some folks here who came from console development who have that style too.
And yeah, the instance where there are two lines of this are actually lines of slashes, the line of = is just one of several versions.
I do remember some old IDE (Metroworks on Mac? I barely used it) would recognize a particular comment style like this and create a kind of table of contents dropdown list, using these to break the list into sections. But putting them between every function would have removed the value in that too.
That's right, the line of == is just in the engine stuff, wasn't it? The tools guys always do slashes for their Doxygen stuff. I remember seeing the == when I worked on Daikatana, but now that I think of it, it was in the Quake 2 source between sections. So actually I guess that does explain things...
I never saw it in console work but that was all pre-Xbox. The Xbox was much, much nicer to program on than the GameCube or PS2 because it was all integrated into Developer Studio and fast instead of in some crazy flaky debugger. So a lot of places went to Xbox as their primary development console. As a result, I presume many recent console programmers are much less divergent from the PC-centric world anyway.
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.
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.
It only sounds. But for complicated algorithms (I wrote a lot computer vision algorithms), there are just too much inter-dependence between two blocks of code making the ideal case of refactoring to serveral small functions impossible. It is OK to write a function with more than 100 LOC.
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;
}
}
That's not really a refactoring improvement. Same number of lines and one more level of nesting. I mean in that particular example it doesn't hurt either way much, but that is the problem with that example.
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.
As amazed as I am when I see 'old' programmers try to justify 100+ line methods because it is 'logically separated'. Just my opinions but I think bad code should say 'refactor me' in the strongest possible terms ;-) (ymmv)
