Beautified That For You
-
Management has introduced a mandatory code beautifier. Hooray!
Ugly old code:
int main(int argc, char **argv) { const char *str = "Hello, world!"; printf("%s\n", str); return 0; }
Beautiful new code:
int main( int argc, char ** argv) { const char * str = "Hello, world!"; printf("%s\n", str); return 0; }
:/
Having received universal acclaim from delighted developers, the tool will be rolled out company-wide because consistently beautified code "looks more professional".
-
-
@clatter said in Beautified That For You:
the tool will be rolled out company-wide
I think you should set the building on fire. The court will understand.
-
Guys! We found the HelloWorldProvider Inc.!
Filed under: Another facepalm would be redundant at this point
-
@Onyx
Dammit, I tried to anonymise, but I knew I'd miss something.
-
@clatter said in Beautified That For You:
consistently beautified code "looks more professional".
This is true. Consistently ugly code, not so much.
-
@Cursorkeys said in Beautified That For You:
@clatter said in Beautified That For You:
the tool will be rolled out company-wide
I think you should set the building on fire. The court will understand.
A jury of your peers will never convict you. But you better get your peers on that jury!
-
@clatter said in Beautified That For You:
Management has introduced a mandatory code beautifier. Hooray!
Ugly old code:
int main(int argc, char **argv) { const char *str = "Hello, world!"; printf("%s\n", str); return 0; }
Beautiful new code:
int main( int argc, char ** argv) { const char * str = "Hello, world!"; printf("%s\n", str); return 0; }
:/
Having received universal acclaim from delighted developers, the tool will be rolled out company-wide because consistently beautified code "looks more professional".
That's god awful. BRACKETS SHOULD ALWAYS GO ON A NEW LINE!
-
@DogsB said in Beautified That For You:
hat's god awful. BRACKETS SHOULD ALWAYS GO ON A NEW LINE!
the prackets did.
the lack of spaces surrounding the parenthesis though.......... that is unforgiveable.
-
@clatter Do you have source control?
If yes, just format things sanely when you work on code and uglify it before checkin.
-
@DogsB said in Beautified That For You:
That's god awful. BRACKETS SHOULD ALWAYS GO ON A NEW LINE!
The mandated bracket placement has been designed to offend everyone equally.
if (condition) { // ... } else { // ... }
@aliceif said in Beautified That For You:
@clatter Do you have source control?
If yes, just format things sanely when you work on code and uglify it before checkin.Indeed, but if I de-uglify on checkout it makes a mess of the diff for work in progress. I'll have to create a de-uglified working branch for each change, and re-uglify before reintegration.
-
@clatter 50% improvement in programmer productivity, in one easy move! 6 LOC => 9 LOC
-
@accalia said in Beautified That For You:
the lack of spaces surrounding the parenthesis
You're one of those
int main ( void ) { ... }
troglodytes? I'm sorry, we can't be friends any more.
-
@FrostCat said in Beautified That For You:
@accalia said in Beautified That For You:
the lack of spaces surrounding the parenthesis
You're one of those
int main (void) { ... }
troglodytes? I'm sorry, we can't be friends any more.
FTFY
-
@accalia said in Beautified That For You:
@FrostCat said in Beautified That For You:
@accalia said in Beautified That For You:
the lack of spaces surrounding the parenthesis
You're one of those
int main (void) { ... }
troglodytes? I'm sorry, we can't be friends any more.
FTFY
Ignoring, for the purposes of this discussion, the {} placement (I just put them in there so they'd be there; I normally put them on new lines), your space before the open paren is just as bad.
-
-
@anotherusername said in Beautified That For You:
@clatter 50% improvement in programmer productivity, in one easy move! 6 LOC => 9 LOC
LOC isn't everything, you know. However, in this example, we can also see a clear improvement in productivity as measured by Columns of Code.
-
@clatter by jove, you're right. Instead of one badly-aligned column, there's two columns.
Actually, shouldn't that be:
int main( int argc, char ** argv ) { const char * str = "Hello, world!"; printf( "%s\n", str ); return 0; }
-
-
My preference:
int main ( int argc, char * argv[] ) { const char *str = "Hello, world!"; printf( "%s\n", str ); return 0; }
Though the exception confirms the rule, and my main two exceptions are
(void)
and(int argc, char * argv[])
, the latter often goes:/* In some header */ #define ARGV(n) (n >= argc ? NULL : argv[n]) /* In the code file */ int main( int argc, char * argv[] ) { char * name = ARGV(1); printf( "Hello, %s!\n", name ? name : "world" ); return 0; }
-
-
@accalia said in Beautified That For You:
int main (void)
The spaces are all wrong. Why would you do something like that? (Unless this was for an overloaded operator, then you'd be ok.)
-
@clatter said in Beautified That For You:
Indeed, but if I de-uglify on checkout it makes a mess of the diff for work in progress.
Just turn off "compare whitespace" in the diff program.
-
@accalia said in Beautified That For You:
spaces surrounding the parenthesis
I don't get this. Why would you want that? I like my spaces inside the parentheses.
-
-
@accalia I don't get it.
int main( void ){ // ahhh....now I feel better }
-
@accalia said in Beautified That For You:
@DogsB said in Beautified That For You:
hat's god awful. BRACKETS SHOULD ALWAYS GO ON A NEW LINE!
the prackets did.
the lack of spaces surrounding the parenthesis though.......... that is unforgiveable.
@FrostCat said in Beautified That For You:
@accalia said in Beautified That For You:
the lack of spaces surrounding the parenthesis
You're one of those
int main ( void ) { ... }
troglodytes? I'm sorry, we can't be friends any more.
@cvi said in Beautified That For You:
@accalia said in Beautified That For You:
int main (void)
The spaces are all wrong. Why would you do something like that? (Unless this was for an overloaded operator, then you'd be ok.)
@boomzilla said in Beautified That For You:
@accalia I don't get it.
int main( void ){ // ahhh....now I feel better }
Jeez, all this in-fighting over some petty whitespace concerns. Look, I've got the solution right here:
main takes arguments as an array of strings, returns an int: ...
-
@blakeyrat said in Beautified That For You:
Just turn off "compare whitespace" in the diff program.
I don't know of any diff program which can successfully ignore the line break changes.
-
this style looks like something a cobol programmer would do, with fixed positions for everything
I would see myself running a different tool on checkout, and putting it back on company style before commit.
-
@clatter said in Beautified That For You:
I don't know of any diff program which can successfully ignore the line break changes.
Hm. I'd have to test, but I think the Stash we use at work does. The other one I use a lot is the one in Visual Studio, and I think you're right-- it won't ignore line breaks even with ignore whitespace turned on.
-
-
@boomzilla said in Beautified That For You:
@accalia said in Beautified That For You:
spaces surrounding the parenthesis
I don't get this. Why would you want that? I like my spaces inside the parentheses.
-
@boomzilla said in Beautified That For You:
@accalia I don't get it.
int main( void ){ // ahhh....now I feel better }
You monster! There should be a space before that
{
.
-
@error said in Beautified That For You:
You monster! There should be a space before that {.
Why?
Do you have a better answer to that question than a meme-post?
-
@boomzilla said in Beautified That For You:
Why?
Because
main
is clearly one word, andvoid
is not part of it, so there should be a space to separate the words.(
is not part ofmain
, as it begins the next portion of the declaration, so it may be lumped withvoid
or stand alone but cannot be lumped withmain
.
-
@Yamikuronue said in Beautified That For You:
Because main is clearly one word, and void is not part of it, so there should be a space to separate the words.
Agreed.
@Yamikuronue said in Beautified That For You:
( is not part of main, as it begins the next portion of the declaration, so it may be lumped with void or stand alone but cannot be lumped with main.
Ah, now we come to the fisticuffs. I see the opening paren as being linked to the function name.
And then I like a space before the
void
because it's easier for me to read. Ditto on the back end, but also because it helps make the end of the parameter list more obvious.
-
@boomzilla said in Beautified That For You:
I see the opening paren as being linked to the function name.
I could almost see that, but the parentheses wrap the list of arguments, and seem to be part and parcel with it; when you pass around references to functions in languages like JS, you leave them off, so they're less bound to the function name than to its argument list. And not having a space would be blasphemy. So I put it before the paren.
-
@Yamikuronue said in Beautified That For You:
@boomzilla said in Beautified That For You:
Why?
Because
main
is clearly one word, andvoid
is not part of it, so there should be a space to separate the words.(
is not part ofmain
, as it begins the next portion of the declaration, so it may be lumped withvoid
or stand alone but cannot be lumped withmain
.While a fair point, that's the wrong character. They were talking about left curly bracket, not left parenthesis.
…although obviously you two have moved on from this point of ry without acknowledging it, which around here is TR
-
@Dreikin said in Beautified That For You:
While a fair point, that's the wrong character.
Oh, I totally misread @error's post because the erroneous left paren jumped out at me too hard for me to even notice the left brace :D
-
@Yamikuronue said in Beautified That For You:
I could almost see that, but the parentheses wrap the list of arguments, and seem to be part and parcel with it; when you pass around references to functions in languages like JS, you leave them off, so they're less bound to the function name than to its argument list.
But saying, "they're less bound to the function name" (which for js, I kind of agree with) makes it more important to my mind to emphasize that this time they actually are bound.
Your style of thinking looks even weirder to me when you make an anonymous function:
var foo = function (blah)...; var my.bar = function( blah )...;
-
@Dreikin said in Beautified That For You:
While a fair point, that's the wrong character. They were talking about left curly bracket, not left parenthesis.
No, I was talking about that paren.
-
@boomzilla said in Beautified That For You:
Your style of thinking looks even weirder to me when you make an anonymous function:
I do them like
var foo = () => {...}; var my.bar = () => {...};
so that point is to me :)
-
@Yamikuronue I was kind of joking about how arbitrary and visceral the supposed "rules" of whitespace are. But somehow I sparked a small flamewar, which means my joke might have been a little too true-to-life...
Filed under: But I do actually prefer
void foo( args ) {
-
@boomzilla said in Beautified That For You:
@Yamikuronue said in Beautified That For You:
Because main is clearly one word, and void is not part of it, so there should be a space to separate the words.
Agreed.
@Yamikuronue said in Beautified That For You:
( is not part of main, as it begins the next portion of the declaration, so it may be lumped with void or stand alone but cannot be lumped with main.
Ah, now we come to the fisticuffs. I see the opening paren as being linked to the function name.
And then I like a space before the
void
because it's easier for me to read. Ditto on the back end, but also because it helps make the end of the parameter list more obvious.@Yamikuronue said in Beautified That For You:
@boomzilla said in Beautified That For You:
I see the opening paren as being linked to the function name.
I could almost see that, but the parentheses wrap the list of arguments, and seem to be part and parcel with it; when you pass around references to functions in languages like JS, you leave them off, so they're less bound to the function name than to its argument list. And not having a space would be blasphemy. So I put it before the paren.
Why have parentheses on parameter lists at all? Several languages seem to get by just fine without requiring them.
let cylinderVolume radius length : float = // Define a local value pi. let pi = 3.14159 length * pi * radius * radius let vol = cylinderVolume 2.0 3.0
-
-
@boomzilla said in Beautified That For You:
@Dreikin said in Beautified That For You:
While a fair point, that's the wrong character. They were talking about left curly bracket, not left parenthesis.
No, I was talking about that paren.
Ah, okay. So @error was talking about
{
and everyone else needs glasses.
-
@Dreikin said in Beautified That For You:
seem to get by just fine without requiring them
That's what They want you to think.
-
@Magus said in Beautified That For You:
HAI MAIN GETS HAZ STRING ARAY //... GIVS A INT KTHXBYE
I may be the only person
leftever that thinks lolcode is kinda funny.IM IN YER LOOP //... KTHX
-
All the formatting above my post in this thread is shit.
public static void main(final String[] args) { if (Boolean.valueOf(args[0])) { System.out.println("I agree with whatever Morbs just said."); } else if (args[0].compareTo(args[1]) > 0) { System.out.println("Parp!"); } else { System.out.println("TRWTF"); } }
Alternatively else if / else on a new line instead of beside the brackets, but I prefer this formatting.
-
@JazzyJosh said in Beautified That For You:
All the formatting above my post in this thread is shit.
So you decided to join in and post some more shit?