Whatever stops my linter complaining.

Seriously though, it's arbitrary, especially when a lot of code might be processed compiled or minified. If your project has a particular standard, I'd use that, it's good to adapt and be able to stick to new rules, it increases your familiarity with other styles, and over time, who knows, you might discover the perfect syntax. A buddha of code.

If it's my own project, it's a case of what seems logical- obviously stick to the same rule all the time, but does the rule make sense given how you're styling the rest of your code. Is it, as a whole, pleasing to read and easy to visually pick apart?

Depends on the language. In JS most teams choose opening brace on the same line.

Crockford gives an argument for why: ASI (automatic semicolon insertion) can in at least one case break your code if you put the opening brace on a new line.

The example is returning an object. This works:

return {
    foo: "bar"
};

This breaks:

return 
{
    foo: "bar"
};

...because ASI means the interpreter decides this means:

return; 
{
    foo: "bar"
};

So instead of an object you get undefined. Curses!

Now you could say that you'll just memorise this rule, use braces on new lines except when returning an object. But as Crockford points out if you have a choice between two ways to do something, one never breaks and one sometimes breaks... why pick the one that sometimes breaks?

And many people, not just Crockford, have pointed out - why pick the method that means everyone on the team has to remember 100% of the time exactly when to use the alternative format?

So in JavaScript at least, opening brace on the same line is generally preferred/idiomatic.

Less lines of code perhaps ?!

Well a lot is taste. https://youtu.be/ZsHMHukIlJY?t=970 here's one person that actually makes a compelling argument about how code should be formated :)

This is styles of writing code. The style of code does not really make any difference in the long run. However, if you try and enforce one style over another then you can entice many, many, many arguements. So best to be flexible :).

The first one is K&R, the second is Allman

See this Indent Styles link for further info on other styles and how they all differ.

It really depends on what standards you follow. Just that it's important to sticking to one. I like the first one.

Also, I do not like using curly for against single line ifs. But, at Hashnode the standard is to use curly line braces even for a single line if. Hence, I stick to it.

Delphi / Pascal programmers who are used to writing:

if (a == b) then
  begin
    // do something
  end
else 
  begin
    // do something else
  end

are often huge fans of placing the curly braces on the next line to emulate what they are used to with begin and end .

The original C-style suggested same-line curly-braces in the late 1970s (and curly braces on the next line for functions if I remember correctly - K&R style). Why, I'm not sure, maybe to save space.

I personally prefer same-line curly braces even though I've had my fair share of Pascal and Delphi many years ago - when in Rome, do as the Romans do.

I'd say it's just that programmers agreed on one or the other in certain languages. For example Rust uses the first style while C++ uses the second. There is no real benefit to either approach.

Personally, I would prefer the second approach any time, because I really like the additional space it provides. So when the common agreement is to use the bracket on the same line, I often leave an additional blank line (just take a look at my source code on GitHub hehe), like so:

function foo(a, b, c, d, e, f) {

    // start writing code here, leaving more "air to breathe"
}