The 1 true style

[Vempele]

auto fib = series!("a[n-1] + a[n]")(1, 1);

Emphasis mine.

Special case: numbers. 1,1 in Finland == 1.1 nearly everywhere else. Also note it's just two arguments rather than five.

[Berengal]

Finland != programming language.

Five-argument functions have even more reason to put spaces inbetween their arguments, possibly even newlines. If the arguments are all single-letter variables then no amount of formatting would help. Actually, a five-argument function is horrible enough without considering how the arguments are laid out anyway.

[stephentyrone]

Actually, a five-argument function is horrible enough without considering how the arguments are laid out anyway.

Heh...

Code: Select all

int zgtsvx_(char *fact, char *trans, long *n, long *nrhs, complex double *dl, complex double *d__, complex double *du, complex double *dlf, complex double *df, complex double *duf, complex double *du2, long *ipiv, complex double *b, long *ldb, complex double *x, long *ldx, double *rcond, double *ferr, double *berr, complex double *work, double *rwork, long *info);


[Xanthir]

Honestly, is there any reason besides inertia that we put commas in at all? I mean, we don't allow whitespace within variable names, and only allow it within explicit values in special circumstances (like if it's surrounded by quotes). A lot of things would be simpler if we just used space-delimited lists for everything.

[phlip]

Well, infix notation, for one. There are more things that can be used as actual parameters besides variable names and quoted literals... and some of those can have spaces in them. Sure, in many languages some of them can have commas in them too, but the comma operator is rarely enough used to not worry about it. Sure, pretty much any expression in C can be written without use of spaces, but having them there can significantly help readability.

Sure, it'd be nice if all languages used LISP-style syntax, but they don't.

[0xBADFEED]

Well, infix notation, for one. There are more things that can be used as actual parameters besides variable names and quoted literals... and some of those can have spaces in them... <snip>

I think Xanthir was probably planning on using parentheses to fix these problems.
So..

Code: Select all

func(x, y + z)  ->  func(x (y + z))  or  ->  func x (y + z)


Personally, I like the comma syntax in function application (at least in C-style languages) and list/tuple-building. It seems more natural to me as it's the syntax used to represent series in both English and many mathematical contexts. In functional languages I do prefer the comma-less function application syntax.

[phlip]

Actually, now that you put it like that, it looks a lot like Logo...

[Xanthir]

Actually, I just completely blanked on the fact that you can pass complete expressions as an argument in an ambiguous way in most languages. It's *so* not an issue in Lisp it didn't occur to me that it would be elsewhere...

That said, parens ftw.

[Berengal]

That said, parens ftw.

commas parens or rpn or solution.

[Ptolom]

I just layout my code the way I feel like at the time. Ive never had a problem yet, though that's probably because I never write anything more than about 300 lines long. I used to be worse. Once (I was only 12 I didn't know any better) I wrote a game in BBC BASIC that was just 1000 lines of hideous, entirely uncommented spaghetti code. I didn't use anything but GOTO then. Luckily it was lost when my hard drive died so I've spared the shame of reading it.

[TjOeNeR]

I prefer Allman style, but for long function definitions, or long conditional statements, I tend to split the code up into seperate lines.

This because I use my IDE (Visual Studio, I'm a C# guy what do you want), in a pretty weird config when I'm debugging.
Locals on the right, output next to call stack in the bottom, and solution explorer to the left. On a 1680 screen with Courier New set a tad smaller than default (gotta love ClearType) I get about 100 columns. So overly long lines do get cut.

I like to use a lot of white space too. 3 lines between functions, and liberally sprinkled single lines in a function. Also no tabs, tabs set to overly large sizes (like 8, I mean WTF) in some editors make the code very unreadable and very indented very fast. This off course because of C#'s way of writing files.

Code: Select all

namespace MyNamespace
{
    class MyClass
    {
        public function DoSomething(string someString)
        {
/*12spaces!*/
             Console.Writeline(someString);
        }
    }
}

[chaosspawn]

Man indenting, who needs that.

Code: Select all

MOVF   f,W ;arbitrary commands
XORWF  f
DECFSZ f,W
GOTO X
INCF   f


That being said, even as an EE I find more occasion to use C nowadays than straight up assembler. When doing that I'm a fan of Allman (brothers).
I still have some stupid affection for the Decrement Skip if Zero command though, and I've never whined about any if statements being hard to follow after learning that was what I got to work with in assembler.

Also on tabs, I really prefer that my editor is always set to the "use spaces for tab" mode, that way there's no actual tab characters in any of my files. Possibly inconvenient, but most IDEs have a "pretty-ify" button that can fix up the style if someone really needs a different indenting scheme.

[stephentyrone]

Man indenting, who needs that.

Code: Select all

MOVF   f,W ;arbitrary commands
XORWF  f
DECFSZ f,W
GOTO X
INCF   f


You say "indenting, who needs that", and then you have your register names nicely indented to line up. O.o

[stolid]

I do the style where braces line up too. Its harder to forget them/not notice them/etc that way. Everyone seems to line up the very first and last brace in a program, so why not indent and do the same for each further embedded block?

[zombiefeynman]

I used to write in I style I'd gotten used to in eclipse:

(These tabs should be 4 spaces by the way)

Code: Select all

int q, g, f=0, u=7;
void do_something(int a, int b, bool c){
   if ((a+b)>9){
      do_something_else(c);
   } else {
      do_something_else(a==b);
   }
   while(c){
      do_another(c);
   }
}

Then I realized I was coding in ... java style! So I quickly converted to K&R, because they are two respectable gentlemen and I can still see what I'm doing when I scrunch my IDE up real small.

If I use anything else - especially one of those styles that says you should give brackets their own line - I end up scrolling up and down far too much.

[Comic JK]

My preferred style is a modified Allman, like so:

Code: Select all

int functionName()
{
    while(conditional)
    {
          //large block of code
          ...
          //is well-defined
    }
    if(shortConditional) shortStatement; //Save lines and read more easily
    if(somewhatLongerConditionalIsToLongForOneLine)
          { multiple(); short(); statements(); } //My personal favorite
}


As usual, it's fine if you disagree; you'll find out the truth when the Great Cleansing comes.

[MHD]

Code: Select all

function someFunc(int arg1,int arg2) { if (arg1) {arg2++; return arg2;} elseif (arg2) {arg1++; return arg1;} else {arg1++; arg2++;}}

Oneliners is the only way

[You, sir, name?]

This is how I be coding, and it is the one true way.

Code: Select all

void main(int argc, char* argv[]) {
    int variable = get_a_value();

    if(variable == SOME_VALUE) do_foo();
    else if(variable == SOME_OTHER_VALUE)
        do_a_longer_command();
    else if(variable == SOME_OTHER_VALUE-1 &&
              another_condition() == TRUE)
        do_something();
    else if(variable == SOME_OTHER_VALUE-2 &&
              another_condition() == TRUE) {
        do_yet_another_command();
        and_something_else++;
    } else {
       do_bar();
       do_something_else();
    }
    return EXIT_SUCCESS;
}


[Ran4]

Spoiler:

Code: Select all

int main(int argc, char *argv[])
{
   int a, b, c;
   int d = 50, e = 40;
   
   if (b)
      doB();
   
   if (d > e)
   {
      doSomething();
   }
   else if (a)
   {
      cout << "E is bigger.";
      doSomethingElse();
   }
   else
   {
      cout << "E and D are equal";
      doSomeThirdThing();
   }

    if (e > d || d > e ||
         (e == d && 1==1))
      cout << "Hello";
   
   return 0;
}

That's the way to do it. Allman style. With tabs. Like above.
I'm more interest in where the comments go. I love inline commenting, something that some people seems hate.

[JordyD]

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...

GNU Indent?

Anyways, this is my style:

Spoiler:

Code: Select all

#include "aclass.h"
#include <iostream>
#include <string>

using namespace std;

int main()
{
        for (int i = 0; i < 10; i++)
                cout << i << endl;

        if (true)
        {
                doStuff();
                doMoreStuff();
        }

        if (THERE_IS_THIS_REALLY_LONG_MACRO ||
              I_NEED_TO_MAKE_MULTIPLE_LINES)
                doStuff();

        string aString = "This is how variables are named.";
        cout << aString << " And if I have multi-line streams, it goes "
             << "like this." << endl;

        AClass aClass;
        aClass.SetText("This is generally how classes and their methods are named.");

        return 0;
}

I usually change my naming conventions to those of the library I'm using, for consistency.

[cerbie]

One of my favorite quips about the issue: You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now.

I like K&R/Java/One True Brace. I don't care one way or another if functions get an extra line for a brace or not.
Real tabs for indenting. I have been in the habit, for quite some time, of using the left and right keys to navigate indentation levels.
Spaces added to align things on new lines, with operators to begin the line.

Spoiler:

Code: Select all

if ( longstuffgoeshere...
     || morestuff ) {
        stuffinblock // assume this is from an 8-space tab setting
}

This way, there is a more obvious cue that it is not a new statement.

For more wordy languages, like VB, SQL (ew on both counts), Ruby, and so on, I throw in an extra indent for a function/routine's begin (if any), body, and end, since there aren't always easily recognizable symbols for the job. FI, some Lua, currently open:

Spoiler:

Code: Select all

tobase10 = function (t)
      local r, fstring = '', formatstring[ t.size ]
      if t[ #t ] == 0 then
         return '0'
      else
         for i,v in ipairs( t ) do
            r = fstring:format( v ) .. r
         end
         r = r:gsub('^0*','' )

         if t.sign == -1 then
            r = '-' .. r
         end
         return r
      end
   end

Without nice little symbols, like braces, I find prefixing the end word with a tab to aid in skimmability, rather than lining it up with the next statement below it.

[Ptolom]

Ok, ok, I've given in and dropped into using Allman.

[tommorris]

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?

As is proved every time you go to a Python blog and read the comments and the crappy blog software pulls out all the spacing and indentation. Really is great fun that. Yet, somehow, the Python programmers still manage to work out what it means despite all the precious indentation disappearing off to the bit bucket.

[stolid]

I like Allman style as well. I like the braces being lined up. It really annoys me when an opening (and closing) brace isn't on its own line. It seems messy to me in those instances.

[Thesh]

I prefer this style

Code: Select all

      
         function a(int j) {
      int i;
      for (i=0;i<j;i++) {
   if (i==j) {
//something
   }
   else {
//somethingelse
   }
      }
         }


I do like allman, and use it for C#. For C, C++, and Javascript I tend to use K&R (with the exception that I don't have a newline before the function brace) just because that is the style I learned when I started with C.

[spupy]

I use the Ctrl+Shirt+F style, because it is the style to which Eclipse formats when I press that key combo.
I have no idea to which real style it corresponds to. Ideas?

EDIT: After checking Wikipedia, it looks like 1TBS - "The One True Brace Style".

[flying sheep]

As is proved every time you go to a Python blog and read the comments and the crappy blog software pulls out all the spacing and indentation. Really is great fun that. Yet, somehow, the Python programmers still manage to work out what it means despite all the precious indentation disappearing off to the bit bucket.

you sound like this was python’s fault.

[Darryl]

On the original topic, back when I was taking programming courses (before I decided I'd rather be a math teacher than a code monkey), I used Allman, with tabs, not spaces. Because I was weird, and liked my 3-space tabs, while most of my classmates kept their tabs at the environment's default.

I definitely found Allman the most readable (and being the default style my professors used helped that a bit, too).

[huangho]

I mostly follow K&R, except that I put the opening brace of a function in the same line as the parameter list. K&R's putting the brace in a separate line made sense when you had to declare the parameter types between the parameter list and the opening brace, but in modern C it is just an inconsistency.

About Lisp: everyone knows that the proper way of indenting an if form is:

Code: Select all

(if (> x 42)
    (then-clause)
  (else-clause))


[flying sheep]

Code: Select all

(if (> x 42)
    (then-clause)
  (else-clause))


any reasoning backing this one?

[Yakk]

As is proved every time you go to a Python blog and read the comments and the crappy blog software pulls out all the spacing and indentation. Really is great fun that. Yet, somehow, the Python programmers still manage to work out what it means despite all the precious indentation disappearing off to the bit bucket.

you sound like this was python’s fault.

It is python's fault. The problem of "whitespace is eaten by various tools" was a known problem prior to Python being released.

Python said "that's ok, I don't mind if the compileability of the code is fragile. I have principles."

[flying sheep]

As is proved every time you go to a Python blog and read the comments and the crappy blog software pulls out all the spacing and indentation. Really is great fun that. Yet, somehow, the Python programmers still manage to work out what it means despite all the precious indentation disappearing off to the bit bucket.

you sound like this was python’s fault.

It is python's fault. The problem of "whitespace is eaten by various tools" was a known problem prior to Python being released.

Python said "that's ok, I don't mind if the compileability of the code is fragile. I have principles."

nah, guido rather said “don’t fucking post code into crappy content management systems, or it’ll look like they had anything to do with us.”

and magically, every content management system written in python has a method to paste code without eating the whitespace and thus is less crappy.

mission accomplished!

[flying sheep]

it’s the same principle as with editors/ides which can’t visualize different kinds of whitespace. they obviously can’t handle code, so go bug the developers, or get active yourself, if you want your crappy editor of choice to be useable.

not python’s fault. i can happily use tab-indentation with space-alignment*, because my editor doesn’t suck, so i instantly see if i have misplaced a whitespace character.

*until elastic tabstobs are widely accepted. also, i seldom have to align much.

[Yakk]

Thanks for illustrating why it is Python's fault? Python would rather break than be impure.

It is a choice. The other choice is to be robust even in the face of other people's failure. Python didn't choose that, so Python is fragile. Python choosing to be fragile is Python's fault.

[Xanthir]

About Lisp: everyone knows that the proper way of indenting an if form is:

Code: Select all

(if (> x 42)
    (then-clause)
  (else-clause))


Um, what? No, the proper way to indent an IF form is "whatever PRETTY-PRINT spits out", because Lisp has an official pretty-printer.

Usually that means you'll get

Code: Select all

(if (> x 42)
    (then-clause)
    (else-clause))


But if the expression is short enough, and it's not already indented too far, it'll just be

Code: Select all

(if (> x 42) (then-clause) (else-clause))


If you're indenting Lisp code manually, you're doing it wrong.

[huangho]

If you're indenting Lisp code manually, you're doing it wrong.

Actually, the indenting style I use is what Emacs does by default. I find it far more legible than putting the then-clause and the else-clause at the same level. (I actually don't use Emacs, though.)

[Xanthir]

I reiterate my statement. If you're indenting in any way other than what PRETTY-PRINT does, you're doing it wrong.

I write my code using whatever default indentation my editor gives me. Then I highlight the block, right click, and select "Pretty Print" before saving.

[huangho]

I write my code using whatever default indentation my editor gives me. Then I highlight the block, right click, and select "Pretty Print" before saving.

Right-click? You're telling me you edit code with a mouse?

Seriously, I don't see why having the editor indent it automatically the way you want is more manual than using the pretty-printer to do it. I would indeed be doing less manual work by letting the editor do it. (I'm arguing just to understand the reasoning behind this; I actually do it wrong and indent my ifs and unwind-protects manually to match Emacs' standard. I have been thinking about switching to Emacs lately, but still haven't done so.)

[Xanthir]

I write my code using whatever default indentation my editor gives me. Then I highlight the block, right click, and select "Pretty Print" before saving.

Right-click? You're telling me you edit code with a mouse?

You kids and your old-fangled console editors. When I was young I used a GUI, and I liked it!

Seriously, I don't see why having the editor indent it automatically the way you want is more manual than using the pretty-printer to do it. I would indeed be doing less manual work by letting the editor do it. (I'm arguing just to understand the reasoning behind this; I actually do it wrong and indent my ifs and unwind-protects manually to match Emacs' standard. I have been thinking about switching to Emacs lately, but still haven't done so.)

Unless your editor is very smart, it's making local decisions constantly, which may not be the same as the decisions it would make with the full context around. It's also more important for an editor to keep your code formatting stable than correct when you're changing stuff in the middle of an expression, so it may avoid making formatting changes that it would make otherwise, even if it detects that your code is now "incorrectly" formatted.

Plus, everyone uses PRETTY-PRINT, because it's built into the language, so everyone is used to the way pretty-printed code looks. Consistency is important.

(For example, the language Go that google developed has a pretty printer as well, which is *required* to be used as part of proper coding style.)

[tipo test]

I like to leave blank lines between my constructions and the working code itself. I consider this

Code: Select all

      for (;;){
         
         while (){
            
            if (){
               
               doIt();
               
            }
            
         }
         
      }

far more legible than

Code: Select all

      for (;;){
         while (){
            if (){
               doIt();
            }
         }
      }

in real world examples. But sometimes leaving them looks excessive and not doing it does still does look ugly to my eyes. Are there any IDEs/editors supporting customable line height? I mean, if a line consists purely of spaces, tabs and carriage return, reduce automatically its height to half.

Btw, what's your opinion/approach in this matter?