6 ms·

>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to redu

>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...

fyi1183 9y ago
Oh but it is, independent of the language. Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, which makes it easier to maintain.
- deleted 9y ago
  [deleted]
- jcelerier 9y ago
  > Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, uh ? for me the less code on each line and the easier it is to read
  - Dylan16807 9y ago
    When it comes to bracket placement, we're talking about empty lines. They don't affect the amount of code on a line.
  - collyw 9y ago
    That depends. Python's pep guidelines has an 80 char wide rule, but I personally find that a lot harder to read than one long line (most of the time).
    - extralego 9y ago
      I find the 80 chars too short but, and this is highly objective, I notice I am more relaxed and usually having more fun when working with shorter lines. The best theory a I have as to why is just that most lines in code are short so long lines require making my eyes deviate from the code structure. If there is a long line, it will probably be out of place. So, my personal rule is to avoid that one or two lines that juts out beyond the lines above and below it. If all lines in a block are long, they are often similar commands/expressions which makes them orderly, and not so discomforting.
    - redblacktree 9y ago
      It's pretty sweet when you need to read code in a console that's limited to 80 characters. Also, it makes it easy to have two files opened side-by-side.
mden 9y ago
Eh, all things equal, the less the number of lines the more readable.
- bipson 9y ago
  I disagree. Consider the absurd example where every single statement is crammed into a single line. Not exactly readable to me? Sometimes more verbose code is more readable, and sometimes it is the presentation, and sometimes this is "superfluous lines", that increase LOC.
  - jorams 9y ago
    That's covered by "all things equal". The argument against placing braces on their own line is that this: if (a) { print(a) } conveys exactly as much information as this: if (a) { print(a) } while taking up more space. The thing the brace tells you is already told by the indentation, so the brace is on a superfluous line.
    - pdonis 9y ago
      > The thing the brace tells you is already told by the indentation Which is true, and of course begs the question: why do you even need the braces?
      - MaulingMonkey 9y ago
        1) I frequently tell my diffs to ignore whitespace so I can see my structural changes without getting drowned in a sea of indentation changes when introducing new scopes. Not viable when diffing python. 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.
Turing_Machine 9y ago
"this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces..." It's not really a valid reason. Unfortunately, there are still a lot of people who think LOC is a valid metric.
- loup-vaillant 9y ago
  Here's an extreme, yet very real example: mandatory Doxygen comments on accessors: /** * 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); Compare with what any sane project would do: int getFoo(); float getBar(); void setFoo(int foo); void setBar(float bar); Multiply that by a dozen such attributes, and what should fit on a single screen spans now hundreds of lines. What you could see at a glance, you have to search for. There's simply no way those utterly redundant comments increase readability. (Yes, the real comments in the real code were just as redundant.) LOC is more valid as a metric than most care to admit.
  - macspoofing 9y ago
    Meh. It's noise but what's the harm? It was generated by an IDE so nobody had to physically type that. And usually no developer will be dwelling on this object or this area of the object. It just sits there doing no harm to anyone. >LOC is more valid as a metric than most care to admit. It's not.
    - taeric 9y ago
      I seem to recall that LOC correlated just as heavily with bugs and other problems as any other measure it was put up against. And, just like every other measure, gaming it leads to a degenerative case. (Can't remember where I saw this, or I would provide a citation.) 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.
defertoreptar 9y ago
Let's say we can see 30 lines on our screen and the average function takes 5 lines with OTBS. That means we can see 6 functions at once with OTBS and 5 with Allman. That makes a difference at least in my case.
- RobertRoberts 9y ago
  Not being a pest here, but how often are you comparing more than 2 functions at a time? I can't say that I have ever dealt with code in over 20 years where I had to deal with more than 2 functions at once. Maybe I am mentally disabled, but I can only focus on one logical task at a time. Can other programmers multi-task their coding?
  - defertoreptar 9y ago
    All the time, but to be honest, it's mainly side by side when I do. This is useful when building one function that acts on some other part of the code and I don't want to scroll / swap files back and forth. 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.
  - MaulingMonkey 9y ago
    Refactoring might have you adding a parameter to a function, and then feeding that additional parameter to the function at it's call sites. Even when you only have one call site and thus are in the "2 functions" case - these two functions are often separated by multiple "irrelevant" functions. 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.
    - RobertRoberts 9y ago
      >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.
lokedhs 9y ago
I've always wonder why no C or Java code formatter tool allows me to use Lisp-style formatting. It's clearly superior, and the popularity of Python should prove that people are OK with not having closing braces on their own lines: void foo(int x) { if(x == 0) { bar() }}
- jrimbault 9y ago
  After having seen a meme, I gave a teacher a project formatted like this: public class Main { public static void main(String[] args) { System.out.println("Hello world!") ;}} We had a good laugh. (that was fine with him, of course as long as it's a joke) 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.
- kazinator 9y ago
  I've written a bit of code formatted rather like this: void foo(int x) { if(x == 0) { bar(); } } That is workable. I have adhered to it (mostly) in this Yacc grammar file: http://www.kylheku.com/cgit/txr/tree/parser.y http://www.kylheku.com/cgit/txr/tree/parser.y 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.

fyi1183 9y ago

Oh but it is, independent of the language. Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, which makes it easier to maintain.

deleted 9y ago
[deleted]
jcelerier 9y ago
> Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, uh ? for me the less code on each line and the easier it is to read
- Dylan16807 9y ago
  When it comes to bracket placement, we're talking about empty lines. They don't affect the amount of code on a line.
- collyw 9y ago
  That depends. Python's pep guidelines has an 80 char wide rule, but I personally find that a lot harder to read than one long line (most of the time).
  - extralego 9y ago
    I find the 80 chars too short but, and this is highly objective, I notice I am more relaxed and usually having more fun when working with shorter lines. The best theory a I have as to why is just that most lines in code are short so long lines require making my eyes deviate from the code structure. If there is a long line, it will probably be out of place. So, my personal rule is to avoid that one or two lines that juts out beyond the lines above and below it. If all lines in a block are long, they are often similar commands/expressions which makes them orderly, and not so discomforting.
  - redblacktree 9y ago
    It's pretty sweet when you need to read code in a console that's limited to 80 characters. Also, it makes it easy to have two files opened side-by-side.

mden 9y ago

Eh, all things equal, the less the number of lines the more readable.

bipson 9y ago
I disagree. Consider the absurd example where every single statement is crammed into a single line. Not exactly readable to me? Sometimes more verbose code is more readable, and sometimes it is the presentation, and sometimes this is "superfluous lines", that increase LOC.
- jorams 9y ago
  That's covered by "all things equal". The argument against placing braces on their own line is that this: if (a) { print(a) } conveys exactly as much information as this: if (a) { print(a) } while taking up more space. The thing the brace tells you is already told by the indentation, so the brace is on a superfluous line.
  - pdonis 9y ago
    > The thing the brace tells you is already told by the indentation Which is true, and of course begs the question: why do you even need the braces?
    - MaulingMonkey 9y ago
      1) I frequently tell my diffs to ignore whitespace so I can see my structural changes without getting drowned in a sea of indentation changes when introducing new scopes. Not viable when diffing python. 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.

Turing_Machine 9y ago

"this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces..." It's not really a valid reason. Unfortunately, there are still a lot of people who think LOC is a valid metric.

loup-vaillant 9y ago
Here's an extreme, yet very real example: mandatory Doxygen comments on accessors: /** * 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); Compare with what any sane project would do: int getFoo(); float getBar(); void setFoo(int foo); void setBar(float bar); Multiply that by a dozen such attributes, and what should fit on a single screen spans now hundreds of lines. What you could see at a glance, you have to search for. There's simply no way those utterly redundant comments increase readability. (Yes, the real comments in the real code were just as redundant.) LOC is more valid as a metric than most care to admit.
- macspoofing 9y ago
  Meh. It's noise but what's the harm? It was generated by an IDE so nobody had to physically type that. And usually no developer will be dwelling on this object or this area of the object. It just sits there doing no harm to anyone. >LOC is more valid as a metric than most care to admit. It's not.
  - taeric 9y ago
    I seem to recall that LOC correlated just as heavily with bugs and other problems as any other measure it was put up against. And, just like every other measure, gaming it leads to a degenerative case. (Can't remember where I saw this, or I would provide a citation.) 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.

defertoreptar 9y ago

Let's say we can see 30 lines on our screen and the average function takes 5 lines with OTBS. That means we can see 6 functions at once with OTBS and 5 with Allman. That makes a difference at least in my case.

RobertRoberts 9y ago
Not being a pest here, but how often are you comparing more than 2 functions at a time? I can't say that I have ever dealt with code in over 20 years where I had to deal with more than 2 functions at once. Maybe I am mentally disabled, but I can only focus on one logical task at a time. Can other programmers multi-task their coding?
- defertoreptar 9y ago
  All the time, but to be honest, it's mainly side by side when I do. This is useful when building one function that acts on some other part of the code and I don't want to scroll / swap files back and forth. 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.
- MaulingMonkey 9y ago
  Refactoring might have you adding a parameter to a function, and then feeding that additional parameter to the function at it's call sites. Even when you only have one call site and thus are in the "2 functions" case - these two functions are often separated by multiple "irrelevant" functions. 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.
  - RobertRoberts 9y ago
    >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.

lokedhs 9y ago

I've always wonder why no C or Java code formatter tool allows me to use Lisp-style formatting. It's clearly superior, and the popularity of Python should prove that people are OK with not having closing braces on their own lines: void foo(int x) { if(x == 0) { bar() }}

jrimbault 9y ago
After having seen a meme, I gave a teacher a project formatted like this: public class Main { public static void main(String[] args) { System.out.println("Hello world!") ;}} We had a good laugh. (that was fine with him, of course as long as it's a joke) 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.
kazinator 9y ago
I've written a bit of code formatted rather like this: void foo(int x) { if(x == 0) { bar(); } } That is workable. I have adhered to it (mostly) in this Yacc grammar file: http://www.kylheku.com/cgit/txr/tree/parser.y http://www.kylheku.com/cgit/txr/tree/parser.y 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.