The 1 true style

[xyzzy]

Lisp style, of course.

Code: Select all

(define (compose f g)
  (lambda (x) (f (g x))))

(define (repeated f n)
  (if (= n 1)
      (lambda (x) (f x))
      (compose f (repeated f (- n 1)))))

Would be a simple set of demonstrations. It's easy to understand, sensible, and compact.

Edit: Crap, one character too far over

[EvanED]

I would just like to go on the record as really disliking typical Lisp indent style, even for Lisp code. I forget what they were now, but after using it for much of the summer I had 2 or 3 concrete reasons why I don't like it.

I think one of them was that if you had code like

Code: Select all

(foo (....)
     (.....)
     (.....))

and decided that you really want to call fizzbaz instead, all the subsequent lines' indentation change too:

Code: Select all

(fizzbaz (....)
         (.....)
         (.....))

Some C indentation styles have this problem, some don't.


EDIT: Oh yes, now it's coming back. Another issue was that, because lines often closed parens from previous lines, even if there was a "logically distinct line" you couldn't necessarily just comment it out. For instance, if you were dealing with a let:

Code: Select all

(let ((a (bar))
      (b (baz)))
  ...)

and think that there may be a computation problem in b, you can just comment out line 2 because then it's syntactically invalid. This led to me usually writing let statements like

Code: Select all

(let ((a (bar))
      (b (baz))
      )
  ...)

instead. There are some other similar issues, but lets were a big culprit here. But then when you do this, the "Emacs rules" for what column the ) should fall at when it appears on its own line are, I think, stupid.

[trickster721]

Code: Select all

if(thisIsALongConditional ||
   thisIsALongConditionalToo)
{
   // stuff
}


Yeah, that's what I thought. Even if people want to annoy me by doing that, using tabs to indent still isn't going to screw it up.

[Rysto]

Yes, it will. If you switch tab widths then things will become unaligned if you use tabs for alignment.

[Pesto]

You would also need tabs of different length for "if", "if else", "while", etc.

[phlip]

At work, I copy the style of whatever code I'm editing at the time... which changes a bit depending on who originally wrote it, but is usually Allman, indented with spaces.

At home, I usually use Allman, indented with tabs, with the tab stop set at 2 characters in the editor. Though, with a couple of changes... if a conditional is very simple, I'll often one-line it, ditto if it's not really part of the algorithm, but just a error condition:

Code: Select all

FILE *fp = fopen(etc);
if (!fp) { perror("error opening file"); return 0; }
dostuffwith(fp);

As for aligning stuff, and multi-lining conditionals, I do that if the various lines are similar:

Code: Select all

if (testpoint(somepoint.x,    somepoint.y,      4) ||
    testpoint(otherpoint.x,   otherpoint.y,   142) ||
    testpoint(anotherpoint.x, anotherpoint.y,  17))
{
  //...
}

Lined up using spaces, of course (if the "if" line was indented by, say, 2 tabs, then the following lines would be indented by 2 tabs and 4 spaces, so they'd line up regardless of the tabstop). If the conditional isn't repetitive like that, then it's usually all on one line, regardless of how long it is.

[EvanED]

As for aligning stuff, and multi-lining conditionals, I do that if the various lines are similar:

Same here. If there are two or more lines of code that are doing similar computations, just perhaps to different variables, and it makes sense to say "this part of the first line is doing the same thing as this part of the second line", those things will usually get lined up.

On an unrelated note, how do you people deal with 2-space indents? Sheesh. :-p

[phlip]

On an unrelated note, how do you people deal with 2-space indents? Sheesh. :-p

Which is exactly why I use hard tabs... if someone else gets my code who prefers 14-space indents, all it takes is changing an option in their editor. Indeed, it'd probably be already set to that, so they wouldn't have to change anything.

It's important to be tolerant of other people's mistaken beliefs, and let them be wrong if they want.

[Hammer]

On an unrelated note, how do you people deal with 2-space indents? Sheesh. :-p

By gluing thumbtacks to the spacebar.

[Amnesiasoft]

As for aligning stuff, and multi-lining conditionals, I do that if the various lines are similar:

Same here. If there are two or more lines of code that are doing similar computations, just perhaps to different variables, and it makes sense to say "this part of the first line is doing the same thing as this part of the second line", those things will usually get lined up.

Same here.

Which is exactly why I use hard tabs... if someone else gets my code who prefers 14-space indents, all it takes is changing an option in their editor. Indeed, it'd probably be already set to that, so they wouldn't have to change anything.

Exactly.

It's important to be tolerant of other people's mistaken beliefs, and let them be wrong if they want.

That's why I try to write any programs I'm working on to be platform independent, or at the very least, ready to be easily modified for another system. People probably think I'm nuts for liking Vista better than other systems, but that doesn't mean I think people should use Vista over the Operating System they prefer. I will try to make people try other things, if they don't like it, then fine, go about using what you prefer, just make an informed decision about what software you are using >_>

[Pesto]

On an unrelated note, how do you people deal with 2-space indents? Sheesh. :-p

What is your specific objection to them?

[EvanED]

On an unrelated note, how do you people deal with 2-space indents? Sheesh. :-p

What is your specific objection to them?

Eh, I was more just poking fun. I don't really have a concrete objection, though I do prefer a larger indent. (8 is probably too deep; I use 4 for personal projects.)

Remember, it's a religious war. I don't need reasons.

[Pesto]

Yeah, 2, 3 or 4 are all nice numbers for indentation. I understand that tab will allow you to change the size of the indent on the fly, but I don't like fiddling with the setting of my text editors. So far, everything I've done has been personal, individual projects, so it's not a big deal. Once I get in an environment where I'm collaborating, then I'll stick to the whole tab indent thing.

For now, as long as the editor has auto-indent, you really don't have to press the space bar all that much. Besides, it's like double clicking, or putting two spaces after a period. Easy.

[xyzzy]

EvanED

You make some interesting points. I tend to just use block defines instead of lets, so I don't run into that much.

If I did, I'd just add the bracket again when I've finished that bit. Or possibly comment out the whole let, and write in a new one, switching the tweaks back into the old when I'm done fixing stuff.

[trickster721]

Yes, it will. If you switch tab widths then things will become unaligned if you use tabs for alignment.

But I just told you not to.

[notzeb]

What if we never align our code? I generally do something like this:

Code: Select all

if ((horribly long condition that I really should split into separate ifs) ||
        (other extremely long condition that I really shouldn't have)) {
    int long_variable_name_number_one = other_very_long_variable_name,
        more_variables = yet_another_variable;
}

That is, I use an extra tab character (or two, in the case of an if) when a line of code is continued on the next line. That way I don't get it mixed up with the actual code within my if statement. Fortunately, I rarely need to split up my if statements anyways (if they're that long I'll replace them with table driven logic).

[EvanED]

What if we never align our code?

Well, then tabs are fine.

Tabs are only broken if you try to align with them.

[Rysto]

What if we never align our code? I generally do something like this:

Code: Select all

if ((horribly long condition that I really should split into separate ifs) ||
        (other extremely long condition that I really shouldn't have)) {
    int long_variable_name_number_one = other_very_long_variable_name,
        more_variables = yet_another_variable;
}

That is, I use an extra tab character (or two, in the case of an if) when a line of code is continued on the next line. That way I don't get it mixed up with the actual code within my if statement. Fortunately, I rarely need to split up my if statements anyways (if they're that long I'll replace them with table driven logic).

I don't like this style because I can confuse the second condition for the body of the if statement if I'm reading the code quickly.

[EvanED]

I don't like this style because I can confuse the second condition for the body of the if statement if I'm reading the code quickly.

It becomes a lot better if you switch to Allman-style for multi-line conditions:

Code: Select all

if ((horribly long condition that I really should split into separate ifs) ||
        (other extremely long condition that I really shouldn't have))
{
    int long_variable_name_number_one = other_very_long_variable_name,
        more_variables = yet_another_variable;
}

I still prefer aligned though.

[yy2bggggs]

I think this is what is being referred to.

Code: Select all

    // with alignment
    while(someParameter >= someUngodlyLongFunctionCallThatDoesSomethingImportant()
          && someParameter <= someOtherImportantFunctionCall())
    {
        doStuff();
    }


[evilbeanfiend]

so you make a name change that changes indenting?

Code: Select all

M-x indent-buffer

fixed

[HappySmileMan]

Spoiler:

Code: Select all

int main(int argc, char *argv[])
{
    // Variables declared on one line,
    // unless there's too much to fit on one line and confortable read.
    // Variables that are initialised will generally be on seperate line.
    int a, b, c;
    int d = 50, e = 40;
   
    // Opening and closing braces get own line.
    // I find it easier to see where statements start and end this way.
    // Single line statements get own line but no braces.
    if (d>e)
        DoSomething();
    else if (e<d)
    {
        cout << "E is bigger.";
        DoSomethingElse();
    }
    else
    {
        cout << "E and D are equal";
        DoSomeThirdThing();
    }
   
    //Double indent the second parts of long comparisons, then go back to single indent for the statement
    if (e > d || d > e ||
            e == d && 1==1)
        cout << "Hello";
   
    return 0;
}

Is what I use, for now, though I'm just a teenager messing around with too much spare time, so I don't have a reason to style like this, it's just a combination of what was in the tutorials I used and what seems easier to read.

Spoiler'd for length

[rrwoods]

teenager messing around with too much spare time

Please, for the love of all that is sacred, keep coding like this. If you actually code like this, you're way ahead of most high school coders, plenty of college coders, and some professionals.

I am not necessarily advocating (or advocating against) your particular style, but the fact that you indent cleanly and stay consistent to any style at all is a blessing to anyone that has to look at your code in the future -- including yourself.

[Karrion]

teenager messing around with too much spare time

Please, for the love of all that is sacred, keep coding like this. If you actually code like this, you're way ahead of most high school coders, plenty of college coders, and some professionals.

I am not necessarily advocating (or advocating against) your particular style, but the fact that you indent cleanly and stay consistent to any style at all is a blessing to anyone that has to look at your code in the future -- including yourself.

Agreed. However I would make one strong recommendation on that style: Please, please get out of the habit of omiting braces for single statement conditionals/loops. It's only a couple more keystrokes, but will save you a lot of time later trying to work out why that line you just added to a loop isn't being executed...

[blob]

Agreed. However I would make one strong recommendation on that style: Please, please get out of the habit of omiting braces for single statement conditionals/loops. It's only a couple more keystrokes, but will save you a lot of time later trying to work out why that line you just added to a loop isn't being executed...

Which is why Python wins at syntax. Humans persistently believe that indentation has meaning, despite the fact that C/C++/Java compilers will happily throw bugs at you to prove that it doesn't. Python turns that around and says, if people think it should have meaning, why not make it so?

[davean]

Agreed. However I would make one strong recommendation on that style: Please, please get out of the habit of omiting braces for single statement conditionals/loops. It's only a couple more keystrokes, but will save you a lot of time later trying to work out why that line you just added to a loop isn't being executed...

Which is why Python wins at syntax. Humans persistently believe that indentation has meaning, despite the fact that C/C++/Java compilers will happily throw bugs at you to prove that it doesn't. Python turns that around and says, if people think it should have meaning, why not make it so?

*I'm* pretty convinced it shouldn't have meaning. Its one of very few reasons I don't use python more.

When it gets impotent whitespace, I will give it the love it deserves. Until then I will find a frozen corner of hell to stash it in.

[_peterb]

I cant stand single bracket lines. Eww.

[btilly]

i find allmen by far the easiest on the eye and finding blocks. also the lines for brackets doesnt bother me much since they make screens that have 80+ rows.

YES! Coding standards that prohibit lines above 80 characters really bug me.

I'm glad I don't work with you then. Because I like to use up extra real estate with having more terminals open, and not with lines of code that are too wide.

But I admit that I once used to believe as you do. I even read Code Complete and did not change my ways. Then I watched a programmer in his 50s with bad eyesight try to edit my code. And I discovered that just because I can read a wide line of code doesn't mean that others can as well. (It was only after this that I discovered how useful it is to have multiple windows available, each of which has multiple terminals.)

[Amnesiasoft]

i find allmen by far the easiest on the eye and finding blocks. also the lines for brackets doesnt bother me much since they make screens that have 80+ rows.

YES! Coding standards that prohibit lines above 80 characters really bug me.

I'm glad I don't work with you then. Because I like to use up extra real estate with having more terminals open, and not with lines of code that are too wide.

Also, got to watch out for printers. If your line of code is too wide, you'll probably end up with a hideous monstrosity printed on to the page.

[zenten]

i find allmen by far the easiest on the eye and finding blocks. also the lines for brackets doesnt bother me much since they make screens that have 80+ rows.

YES! Coding standards that prohibit lines above 80 characters really bug me.

I'm glad I don't work with you then. Because I like to use up extra real estate with having more terminals open, and not with lines of code that are too wide.

Also, got to watch out for printers. If your line of code is too wide, you'll probably end up with a hideous monstrosity printed on to the page.

Prin...ters?

I think I heard of those. They're some sort of static monitor, right?

[Amnesiasoft]

Prin...ters?

I think I heard of those. They're some sort of static monitor, right?

Yes, something like that. I haven't used one in so long, ever since that ink cartridge slot in mine broke

[HappySmileMan]

Maybe I'm being stupid, but why would you print code? Anyone who can use it needs a computer anyway so why not just compress it and give it to them, nowadays CD-RWs are probably a wiser move than printing anyway, in every way (including financially once you re-use it a few times.) and most people have fairly fast internet

[EvanED]

Maybe I'm being stupid, but why would you print code? Anyone who can use it needs a computer anyway so why not just compress it and give it to them, nowadays CD-RWs are probably a wiser move than printing anyway, in every way (including financially once you re-use it a few times.) and most people have fairly fast internet

I've printed code plenty of times. It's nice to be able to look at it in places where you don't have a computer, or if you want to scribble on it as you try to figure something out, or if you just want to get away from the computer. (Or if you're writing a book, tutorial, homework assignment, etc.)

I limit my line lengths to about 110 characters. Visual Studio wraps at about 120, and that's what I use for printing code (even when I'm not using it for editing); it does a better job than the couple other things I've tried. Printing so that only 80 columns fit on a page means that your font is too big. It's annoyingly large and wastes paper, like using wide ruled paper instead of college ruled.

[btilly]

Also, got to watch out for printers. If your line of code is too wide, you'll probably end up with a hideous monstrosity printed on to the page.

Perl Best Practices suggests a limit of 78. Enough to survive one round of quoting in email without wrapping.

If you send a lot of patches around inside of plain text emails (lots of open source project do), then this makes sense.

[Anpheus]

For myself, I like Allman. However, my main requirement for style is that, whatever you decide to do, do it consistently! I regularly get handed code from beginners whose reaction to suggestions to maintain a consistent style is "Do I haaaaave to?" Then, after listening to them whine, I get to plow through code that uses three different indenting styles selected at random when they bother to indent at all. Grrrrrrrrr...

It's awful, isn't it? At least with the advent of easy to use IDEs, new coders these days will simply stick with the IDE's default open/close brace and indentation pattern and never mess with. I completely agree, consistency > everything_else. If you're going to have a pattern, use it everywhere, so at least I won't be confused when you change it.

[adlaiff6]

I assume that the closer my C looks to python, the better.

[disq]

I'm a Whitesmiths fan, it kinda developed naturally over the years for me.

To quote Wikipedia:

Code: Select all

void MyFunc ()
{
while (x == y)
    {
    something();
    somethingelse();
    }
 
finalthing();
}


Though I sometimes also use one-liner conditions and worse, align them with spaces. Like this:

Code: Select all

if (x == y) doWop();
_ _ _ _else thatThing();


Of course the trick is to only use spaces after base indentation (and of course I sometimes violate that)

[segmentation fault]

for functions:

Code: Select all

return type
name(args)
{
  blah blah
}

for if/whle/other stuff:

Code: Select all

if (stuff)
{
  fdsa
}


i find this the most readable and organized.

[Pobega]

In personal projects I like to use K&R, but for school and other things where my code will be read by others I lean more towards Allman style since it‘s much easier to read in my opinion.

[Xeio]

[codeblock]

Is what I use, for now, though I'm just a teenager messing around with too much spare time, so I don't have a reason to style like this, it's just a combination of what was in the tutorials I used and what seems easier to read.

Wow, that an exact mirror of what I do basically (even the double indent for continued lines ). I'll admit though that I'm occasionally lazy and let the editor fix my indenting (though it depends on if I like the editor's indent style, visual studio is my favorite editor right now).