Coding style and formatting

[Creative Magic]

Hello everyone!

I would like to discuss a philosophical topic, not strictly a black and white issue, but rather the gray area of preference of how we write our code.

Namely I would like to discuss opening/closing braces: {, (, [ etc.

Consider two function definitions

private function myFunc():Void {
    if (condition) {
        // implementation here
    }
}

and 

private function myFunc():Void
{
    if (condition)
    {
        // implementation here
    }
}

The first one is most commonly seen (in my experience) in most ECMAScript languages I got to work with. The second one is...well...what I believe to be prettier and easier to work with.

That got me wondering - am I wrong or does everyone got used to a style that's "pretty"?

I've tried to do a little research how come the first style got adapted over the second one, because I did see code written like in example No.2. The conclusion of my simple research ended up with a small trivia that originally No.2 style was always preferred, but book publishers didn't want to waste too much space and recommended to save space by putting the opening bracket on the same line and that's how it got solidified with people who were learning how to write code from these books.

I would like to point out that I do not want a holy-war on what style to use, but rather discuss on what style "looks better", and maybe if there's a different reason to use one style over the other?

If you have your own style that you find to be better - please share and explain why you prefer it.

PS: I do not question the idea of adapting your coding style to the project you're working on, I'm talking about your preference in your own projects.

[Nico May]

I believe that loosely, the first was created by the inventor of C (there are variations as well on whether else's are inline with the bracket, and whether single expressions use brackets or not, but that still fits your first example).

Personally, I prefer #1 as it looks prettier to me, less rigid, and it wastes less space, there being no content you might wish to add into the blank spaces, I see little reason to place them there. For readability sake I would rather inject blank lines where I feel a distinction is necessary inside my blocks.

That's just my opinion though, and I used to prefer #2, I think it's mostly just a matter of what looks nicer to you, most of the supposed benefits of different styles are just justification for people liking their own style.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Michel Romecki]

Hej,
In Haxe all is a block "{}".
//if( condition )
{
...
}
So writing like that, we can easily comment just the line where the "if" is and so the block is executed...
But I think it's a question of personal feeling

[Dion Whitehead Amago]

I prefer the second.

My brain matches up braces easily when they are aligned, but when the first brace is at the end of a line, I have to look for it, and that takes time.

It would be great if we had a haxe code formatter, like what Eclipse has for Java, where you can specify pretty detailed rules about how your code looks, and format it for yourself, then when you commit, just format it back to the standard the group has settled on. 

[Hugh]

I prefer the second one from a aesthetic point of view - the vertical matching appeals to me.

The first for abandons the matching for code-density, which has some advantages. Especially with some closure syntax, where I would sacrifice the matching for density, like

if (condition)
   setCallbackArray( [ function(e) {
      someMoreCommands();
      someMoreCommands();
      }]);


if (condition)
{
   setCallbackArray(
      [
         function(e)
         {
           someMoreCommands();
           someMoreCommands();
         }
      ]
   );
}

.. and everything in between.  Maybe it would change if there was more than callback, or if they were longer.

I think it can affect how you visually parse things.  If your brain can look at it and go "oh, and array of closures" then you are good.  If you have to go "huh, what brace does this one match with" then maybe you have chosen wrong.

I think the only absolute in programming is that there are no absolutes.

Hugh

[jacek szymanski]

I prefer the first, indent is enough for me and seeing the "header" (function, if, for...) as the last less-indented line gets better to me. And in languages like Python there is only indent. To each their own, I guess.

As for formatter, I am using astyle with somewhat tweaked settings for Java. It doesn't support Haxe and sometimes gets lost on things like inline metadata or other Haxe specific stuff, but it's good enough so far. I usually run it and then review changes with git add -p, which clearly doesn't scale, but so far it works for me...

js.

---

From: Dion Whitehead Amago
Sent: Wednesday, December 07, 2016 9:32PM
To: Haxe
Subject: [haxe] Re: Coding style and formatting

--

[Jérémy Faivre]

I used to prefer the second version, until I started to use more python-like languages that don't have braces at all.

At the first place, second option may look "cleaner", with braces aligned etc... but if you look at the code in terms of blocks, then you might prefer to save a line so that the code depending on a condition is in the same "block" as the condition itself (same for loops, functions).

So I guess it mostly depends at HOW you look at the code, and whether you think braces are important or just noise.

[Juraj Kirchheim]

Take this: "readers of Lisp programs do not match parentheses, but use indentation."

;;; bad
(defun f (x)
  (when (< (g x) 3)
     (h x 2)
  )
)

;;; good
(defun f (x)
  (when (< (g x) 3)
     (h x 2)))

Languages with white space significant syntax acknowledge that - although while reading them is easier, editing can be a PITA.

If you want to be philosophical about this, then I suggest pondering the fact that 50 years later editing text files and formatting stuff by hand is still a thing. Assuming this really mattered, I'm pretty certain we'd be editing structures rather than strings. This is not so, because the true challenge is to achieve intelligibility across a whole code base, and that battle is not fought on a character level. The most beautiful formatting will not help you one bit when facing a shitload of poorly named meatballs all tangled-up in never-ending spaghetti.

So my advice is not to spend too much time on this. Clearly, this is wrong:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

    goto fail;

    goto fail;  /* MISTAKE! THIS LINE SHOULD NOT BE HERE */

But as long as your indenting follows the structure rather than actively obscuring it, you're doing just fine ;)

Best,

Juraj

[al...@rgames.jp]

Juraj,

I agree with the part where you mention that line-formatting is not the only thing that matters in writing good, understandable code. However, in case where you have many parenthesis on the same line opening and closing - it might contribute to some fuzzy math type of error, where it's just hard to see what part of an expression belongs to what part/block.

I think indentations and parentheses will enhance readability. Especially in parts of code where you need to do some multi-dimensional array sorting and searching.

Also...I actually thing that the "bad" example of Lisp code is better and more understandable than the "good" one. At least for Haxe, not sure about Lisp. But I guess that's why it's mentioned to be a thing of preference.

[Ian Harrigan]

I think its about consistency, no? When i first start developing i was using

if (x)
{
}

For reasons quite unknown to me, probably concise, it became

if (x) {
}

which still seems much much neater to me now, and certainly incorrectly i see the former as a "new" developer (i know this isnt true - its a bias). But all that said and done, i always attempt to use whatever the codebase does. If its my codebase i prefer my style (and i would prefer it if people used that), if its not my codebase then i would try to use theirs, as i would assume they too like their code style. 

There is of course no reason to do this, but to just put it to an extreme:

if (a)
{
  if (b)
  {
    if (c)
    {
      if (d)
      {
      }
    }
  }
}

vs.

if (a) {
  if (b) {
    if (c) {
      if (d) {
      }
    }
  }
}

... i know which i prefer. :)

[Hugh]

I actually used to use quite a lot of:

if (a)
   {
   doSomeStuff();
   }

being the most "syntactically correct" version, IMHO.  But you can't program in a vacuum, and no one else seemed to use this, so I gave it up.  Now l look at old code, and it looks weird.

I think the "ultimate" answer is probably not exactly Juraj's writing structures, but storing the program in some canonical form like "braces on own line, always use braces (no single lines blocks) tab indents, no line breaks" and then letting the editor "view" the file any way the programmer wants. But when its saved, it goes in the "One True Format" -  is does not really matter which.

This solves the preference problem.

I often think I would like lines with only a brace on them to be drawn half height, which would help with the code density issue too.

[Cristian Baluta]

I use the first, i think is a waste of space the latter and this makes the code more unreadable. I however leave empty lines where it becomes more readable.

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Băluță Cristian
http://ralcr.com
http://imagin.ro

[JLM]

if( a ){
    doStuff();
} else {
    otherStuff();
}

I think it's useful to have space around the variable.

function( a: String ): Bool {
   return true;
}

Since our eyes know 'if' and 'function' etc... and so it is what's inside the brackets that is more important than what is next. I used to do the more verbose style but the reality of matching braces is not worth the advantage of being able to read more code on screen with the tighter style. Generally the style that allows you to scan code quickly is what is most important when choosing a style.
I quite often put a bit of effort to line up types when declared so that I can scan a list quickly as our eyes can move quicker.

var total:   Int;
var name: String;

But this rule is one I use when it fits, rather than religiously. It can slow you down when coding, which can actually be a good thing, as you think about them more. Ideally coders should use thier prefered style, and the IDE editor should switch the code style for them.

Really this thread is pointless you try to stick with the style of the code you are editing if your rewritting the project because it sucks then up to you if you want to change the style.  Since we all use libraries the styles will differ in most big projects, so best to keep to a style for a library but no reason to insist every library in a project uses the same style?

Often the team leader the best coder dictates a style, but really they should consider using the style of the lowest coder, and instead being the one to adapt, as it will likely slow them down least of everyone if they are already a very good coder. I actually like to see consistant clean simple code rather than care too much which style is used.