uh ? for me the less code on each line and the easier it is to read

Sometimes more verbose code is more readable, and sometimes it is the presentation, and sometimes this is "superfluous lines", that increase LOC.

The argument against placing braces on their own line is that this:

    if (a)
    {
        print(a)
    }

    if (a) {
        print(a)
    }

    if (user.exists()) {

        destroyHuman(user);
        hideRemains(user);
    }

Which is true, and of course begs the question: why do you even need the braces?

2) I semi-frequently make indentation mistakes when resolving merge conflicts. In braced languages this is fixed by an autoreformat. In unbraced languages, I have to take a lot more care with merging, lest I end up in yet another lengthy debugging session ending in facepalms - or worse, check it in.

3) Redundancy in the face of typos and whitespace destroying mediums such as many pieces of web technology - comments sections, forums, etc.

    if (a) {
        print(a)
    }

Could just be if (a) print (a)

Except in perl, where it's

    print (a) if (a)

    if (a) { print(a) }

Maybe I am mentally disabled, but I can only focus on one logical task at a time. Can other programmers multi-task their coding?

I more meant it in the sense that it's nice to be able to soak in more of the code at once and avoid unnecessary scrolling.

The less scrolling, tab management, and other context switching I have to do to look at those "2" functions, the easier it is on my memory.

I don't disagree, but the sentiment seems to be "fit everything on the screen at all times", which seems like one of those rules that may take more time to implement than it saves in actual time.

I work on projects with upwards of 100k lines of code consistently, the very idea that anything relevant will fit on one screen is absurd, so I am always curious what kinds of projects people work on where the relevant code is literally within a half screen of each other.

Given that above description, you can probably guess I don't have everything on screen at all times, not even close. But I'll refactor off small files of related functionality where I can, subdivide things that are getting unwieldy, etc. - put private/static functions near the public/exported functions that call them, break things up into (sub)modules, etc. and get good grouping.

> I don't disagree, but the sentiment seems to be "fit everything on the screen at all times", which seems like one of those rules that may take more time to implement than it saves in actual time.

Taken to the extreme, any such rule absolutely will. I certainly don't have that as a hard and fast rule. Or even as a guideline per se - it's more a faint but distant dream, or perhaps a feverish hallucination, a reminder of codebases past. But there's often plenty of cruft and low hanging fruit that can be fixed up in these codebases. Everyone has their "just one small change" to check in, so things build up and they don't jump to "okay, this is one line too many - time to refactor."

I practice pain driven development - when it's getting to be a pain to keep enough of something my head to do whatever sweeping changes or overhauls I might need to do, see if some pure or near-pure refactoring changes it. No expected behavior changes, often not even class or structural changes - often literally just regrouping code by topic and category via cut and paste. Horrific diffs, but low-risk checkins, and often a lot easier to reason about afterwards, and suddenly related code is often on the same screen.

(Although far from always.)

Yes, it's nice when things are close together, but in my case it's so rare as to not be point to consider trying to achieve, but more like a mental joke like "Hey, Bob. Come here and check this out! Two functions and template I am working on all fit on the same screen!" And Bob's like "wooooah, dude". And then we take a group selfie with my monitor and have a laugh, print out a poster of the selfie for the bulletin board for a few months, then throw it away during a cleanup and move on...

But to have people say "It's important to save whitespace so stuff can all be on the screen to avoid context switching" seems completely and utterly pointless.

    void foo(int x) {
        if(x == 0) {
            bar() }}

    public class Main                                        {
        public static void main(String[] args)               {
            System.out.println("Hello world!")             ;}}

PS: getting back to the original topic, imo, formatting style should be project-wide rules set at the beginning or during refactoring. Don't get too hung up on style as long as it stays consistent.

    void foo(int x)
    { if(x == 0)
      { bar(); } }

Just in the grammar; not in the supporting functions.

It's an attractive style for C statements embedded in another language, because they look more like capsules somehow.

It's not really a valid reason. Unfortunately, there are still a lot of people who think LOC is a valid metric.

  /**
   * Get the foo
   *
   * @return the foo
   */
  int getFoo();

  /**
   * Get the bar
   *
   * @return the bar
   */
  float getBar();

  /**
   * Set the foo
   *
   * @param foo the foo
   */
  void setFoo(int foo);

  /**
   * Set the bar
   *
   * @param bar  the bar
   */
  void setBar(float bar);

  int   getFoo();
  float getBar();

  void setFoo(int   foo);
  void setBar(float bar);

LOC is more valid as a metric than most care to admit.

case class Baz(foo: Int, bar: Float)

Gives you a free hashCode, equals and copy as well.

int foo; float bar;

That can later be changed, when the need arises.

>LOC is more valid as a metric than most care to admit.

It's not.

Not all of it, actually.

> nobody had to physically type that

We totally had to read that.

> And usually no developer will be dwelling on this object or this area of the object.

Well… yes, usually. Sometimes however we did want to pay more attention than usual. At that point the original dev would have made a real comment. And that comment was lost in the noise, so you couldn't even distinguish between real comments and useless boilerplate.

I'll repeat my current gut feeling. Intrinsic measures of software quality are terrible as guides for how to write code. They are decent at predicting quality, but are not usable in a prescriptive way to write quality code.