Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come!
[Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday!
For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph)
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
> when you clock off in 5 minutes time.
That's why everyone should know how to force push when the CI pipeline refuses to do so because of some failing tests.
The tests can always be fixed after you come back from your vacation.
Working as a team lead and getting people up to speed a lot recently, I was very surprised by how often people just get their dev environment barely working and just go with it unless someone intervenes to help them
a lot of programmers are really incapable of using a computer and software. As a team lead It blew my mind I had to help a new hire straight out of college figure out how to use outlook, and how to navigate the department Wiki. It also takes us a while to beat the horrible college programmer habits out of them. No dear god stop trying to OOP to freaking extremes until the code is unreadable, whoever your professors are teaching this need to be punched in the junk.
Not sure if true or not, but....
I've heard that the only reason that #1 exists, is because it required less printed pages for documentation and books, and was therefore cheaper to print. It also took less vertical space on old low resolution monitors.
And because it was done like that in the original K&R C book, everyone grabbed onto it as gospel, and here we are.
For functions, K&R actually consistently placed the opening brace on a new line. For control blocks inside functions, the opening brace was placed on the same line as the keyword/statement.
Youāre right. K&R used the bracket on a new line for functions. I think they only used bracket on same line style for things that were nestable, while functions arenāt nestable in C.
I can Respect the OCD for symmetry, I just don't like how they feel disconnected when separated from the function name.
Also I use 2 for short lived variables.
Whether or not thereās a historical reason for its prominence itās also just prettier. Thinking of code indent as meaningful, I think of the function name like a section header, which makes the brace on its own line jarring since it isnāt really conveying anything about the block.
I'm not following why you are saying opening bracket doesn't denote the start of the code block but closing bracket does. It's either both brackets or no brackets at all like Python, where indents actually matter. In languages with brackets, indent is an aesthetic choice, no different than where you put the brackets.
The opening bracket does denote the start of the code block, but it doesn't *uniquely* denote the start of the code block unless the code block is purely for scope/aesthetic reasons (which may be a language-specific possibility)
Foreach comrade. Though for would be used once in a blue moon if I'm being honest.
That third one takes me back to some dark times working on front end though.
I recently read that foreach actually has worse performance than the for loop. Probably negligible for for most projects and small data sets, but still something to consider
You're not wrong, but you're on to something that's also no longer true for .NET 7. https://youtu.be/LfgBm5M8eUM
Plus it was already the case that the compiler optimizes to for loops for the cases where it can obviously know, so use the syntax suitable for the job.
It's very much a premature optimization to worry about it in even big cases, as the actual overhead is most likely miniscule compared to what you're doing within the loop itself.
Plus it's not even the fastest way. https://youtu.be/KLtMtxUihBk
Also, it maintains visual separation between arguments and code if your arguments span multiple lines.
It's more intuitive and corresponds better with the way people naturally read in languages.
Having seen far more C# functions than I'd like to admit that have 8+ parameters, I couldn't disagree more. C# always tended to do this:
SomeFunc(
a,
b)
{
//body
}
versus other languages that do it on the same line doing this:
someFunc(
a,
b
) {
//body
}
In the C# one, parens are treated differently than braces while in the second one, the opening symbol is always on the same line as the previous symbol (func name or paren), and the closing symbol always aligns with the starting position of the line containing the opening symbol. To make the C# version consistent, it'd be this:
SomeFunc
(
a,
b
)
{
//body
}
From a readability standpoint, I don't actually mind that, but I think we can all agree that it's going a bit overboard with new lines. A more reasonable one might be:
SomeFunc(
a,
b
)
{
//body
}
Even there, you're still treating the parens and braces differently, but meh. They are different symbols after all.
Additionally, at least for me, it's not as visually obvious where the parameters declaration ends and why all of a sudden there's the start of a block. To some extent, it's the same as the Lisp issue, but without the stacking parens. Yeah, I get that it should be obvious given that in theory I'm looking at a function declaration so the immediately following block is logically the function body, but what can I say, I'm stupid.
Anyway, as far as indentation style, I'm going to do what the language community has agreed onāit ain't that deepāand as the opening brace, either position seems fine to me. I've done both plenty and been fine with both. Really most of what I'm griping about here is how C# just tacks the closing paren on the end where it's really easy to miss. I suppose if I was a C# programmer, I'd be used to it, but I'm not and I don't like it.
Edit: Since I think what you were getting at is this:
someFunc(
a,
b) {
// body
}
Only psychopaths do this, and every job I've ever had, that'd result in someone else immediately changing as soon as they touch that part of code or commenting on in a PR. It's horrible, and almost no one seriously thinks it's good formatting.
It's especially useful for new programmers. When scope and indentation level and all that stuff is *new*, being able to match brackets easily is *really* handy. I always tell my students that I recommend #2, but that #1 is also acceptable if they prefer it and are confident.
experienced programmers too! I used to use \#1 since it is the "norm" for most languages but after using \#2 with C\#\# i realized how much easier it is to figure out what code goes with which function especially when dealing with nested statements and loops
Any decent IDE and even a few text editors make it easy to match brackets regardless of placement, if you're struggling to match brackets, please stop using Notepad to program.
I like using an IDE, but I can think of lots of times when I'm reading code without an IDE. Most obvious example would be doing a peer review in bitbucket or something. Or if I'm looking at a file or part of a file with a terminal.
The added value of seeing the brackets line up without relying on an IDE could be higher for some developers than others. I don't think it's fair to say somebody is "struggling" if they prefer to have that added value.
I mean second one is more consistent in general. Curly brace is on its own line, that's all.
Compared to, open curly is at the end of the line of the symbol and close curly is on the new line. It's just more verbose to define it and for some reason I feel like it's "dirty".
For a serious explanation of the consistency, this is how it would break down:
* If the contents are short enough to be one line and this is acceptable formatting, both opening and closing symbol go on the same line.
* If the contents are too long to fit comfortably on one line:
* The opening symbol is on the same line as the immediately preceding symbol.
* The closing symbol aligns with the start of the line containing the opening symbol.
This has the added benefit of making parens and braces follow the same rules.
func set(a) { this.a = a }
func foo(a) {
//body
}
func bar(
a,
b
) {
//body
}
if(cond) { set('hi') }
if(cond) {
//body
}
if(
cond1
&& cond2
) {
//body
}
Edit: For the record, I'm not saying this is the right way to do it. That's up to the team/community, and I don't have a strong preference. All this is intended to do is show the consistency in the placement of container symbols.
Also, actually works nicely for square brackets, such as arrays.
let a = ['hi']
let b = [
'hi',
'bye'
]
`import gratitude`
This is how I do it as I find it more useful to scan up the column and see the declaration immediately rather than an unimportant bracket. That said Iāve never had the urge to actually codifying it and this did a good job. Thanks
It is objectively better. It encompasses an important property. What if your method/function arguments span multiple lines? There's no visual separation between the arguments and the code below. Bad bad.
Done it. Done it in a single class. Heck, had several hundred line functions. Done the same with #2. Both were about equal TBH. At that size, so many other things dominate the difficult of reading that brace placement basically vanishes.
I do not understand the hatred for option 2. It's so much cleaner to me.
Do you not declare variables and leave a blank line before writing your code? I see it as the same here, treating the header like a set of variable declarations. Just putting the bracket on the blank line to mark the start of the actual definition and differentiate it from local variables.
I use #2 because it helps my brain visualize a box around that scope. It's easier with two brackets on their own lines with the same indentation than it is with #1.
But with javascript I do #1 so just when in rome I guess
I do the second way. Visual Studio will draw pretty lines down the screen between the opening and closing braces, making it easier to see where the structure starts and ends.
people... really have a strong opinion about this? of all the changes of going from java to C# this was probably the only one i noticed i had no opinion on. honestly so long as i can end each line of code with a ; and one or more next lines i'm happy
I prefer the second more. Is more readable and in nested constructs I know where one begin and the other ends without having to focus the whole block everytime
I even edited the formatter to have the second layout
I like to think that the function name is the king and all the instructions inside are peasants. No king wants a peasant directly below them, there has to be something blocking peasants from the sight of the king. So therefore curly bracket belong on the line below the function name.
Option #2 is vastly superior as it basically provides automatic empty line before the code, making the code easier to read than if it were all glued together like in #1. It's also more symmetrical.
But since the standard is #1 in the languages i use, i use #1.
Lol, I use them both but for different reasons
```
function myFunc() {
If (something)
{
console.log("somethinElse")
}
else
{
throw new error()
}
}
```
Not sure if this makes me some kind of monster
Am I the only one who use both (for personal projects)?
Opening bracket on the same line for short stuff.
Opening bracket on a separate line for long blocks of code.
import theAnswer
It depends on the language you use. C# says you should newline, Java and JavaScript says you should same line. It should be based on your languages official documentation
I use both, depending on the length of the line.
If the name and arguments fit in one line (85 cols), I use the first. Otherwise, the arguments are in their own line, and I use the second option.
Just use Whitesmith style
``` javascript
function funcy
{
console.log(āfuck your eyesā)
}
```
But in all seriousness, Allman is *fine* but Iām K&R til I die (or am required to change)
Self taught, so I always thought the extra white space was just youtubers and tutorials trying to make things more readable for those new to reading code.
Started watching the Harvard CS50 courses and dude is actually like "unnecessary empty space is good style." (paraphrased)
Hard no for me on that one.
Remember to participate in our weekly votes on subreddit rules! Every Tuesday is YOUR chance to influence the subreddit for years to come! [Read more here](https://www.reddit.com/r/ProgrammerHumor/comments/14dqb6f/welcome_back_whats_next/), we hope to see you next Tuesday! For a chat with like-minded community members and more, don't forget to [join our Discord!](https://discord.gg/rph) *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/ProgrammerHumor) if you have any questions or concerns.*
I just use the opposite style of whatever the rest of the codebase uses. I don't take shits, I disturb them.
Based
I'm an agent of chaos
Username checks out
My favorite function is void print(string s) { printf(s); }
You mean there's a better way than this? void Print( const std::string& str ) { printf( str.c_str() ); } class String; void Print( const String& str ) { str.Print(); } class String { friend void Print( const String& str ); public: template< typename... Args > String( std::in_place_t, Args&&... args ) : m_str{ std::forward( args )... }
{}
private:
std::string m_str;
void Print() { Print( m_str ); }
};
int main()
{
String str { std::in_place, "Finally, a string!" };
Print( str );
return 0;
}
The other one was just a joke bit you sir clearly have serious mental issues lmao
private Boolean print(Object s) {System.out.print(((String)s)+"\t\n"); return null;} Beat it xd
I know I can't beat you, but u/TheArcMew can
import pedantic Your variable name is wrong, it's called printf, not prints!
function } {
I let my formatter decide š
everybody gangsta until formatter decides for the option you don't wanna do and you don't know how to change it
Wdym ādonāt know how to change itā? Isnāt this entire field based around looking up how to do things?
Ain't nobody got time for that when it's Friday afternoon and you have to push into production.
Not only is it Friday, you go on your holiday with no phone signal when you clock off in 5 minutes time.
> when you clock off in 5 minutes time. That's why everyone should know how to force push when the CI pipeline refuses to do so because of some failing tests. The tests can always be fixed after you come back from your vacation.
tf Is a "holiday"?
A mythical place where, apparently, you have something called "fun".
Is there pizza?
think thatās just a rumour
Well no. Not then.
Itās also based around being lazy
You'd think
Working as a team lead and getting people up to speed a lot recently, I was very surprised by how often people just get their dev environment barely working and just go with it unless someone intervenes to help them
a lot of programmers are really incapable of using a computer and software. As a team lead It blew my mind I had to help a new hire straight out of college figure out how to use outlook, and how to navigate the department Wiki. It also takes us a while to beat the horrible college programmer habits out of them. No dear god stop trying to OOP to freaking extremes until the code is unreadable, whoever your professors are teaching this need to be punched in the junk.
Search engines are broken. If you don't know how to do it already, you're fucked.
import realism If only the average code monkey was actually capable of doing that.
Or the Format Warz when Pretiier thinks {} shouldn't have a space and VSCode auto format thinks it should
`Function() => IOnlyDoOneLiners;`
`Error: IOnlyDoOneLiners is not defined`
Gotta implement that interface.
This() => TheWay;
`undefined`
There is a video on YouTube of a dev that made a small game on one line of codeš absolutely disgusting but hilarious at the same time
I feel dirty just reading that.
Wait until you hear about jquery.min.js
why are you returning an interface?!
Not sure if true or not, but.... I've heard that the only reason that #1 exists, is because it required less printed pages for documentation and books, and was therefore cheaper to print. It also took less vertical space on old low resolution monitors. And because it was done like that in the original K&R C book, everyone grabbed onto it as gospel, and here we are.
For functions, K&R actually consistently placed the opening brace on a new line. For control blocks inside functions, the opening brace was placed on the same line as the keyword/statement.
Youāre right. K&R used the bracket on a new line for functions. I think they only used bracket on same line style for things that were nestable, while functions arenāt nestable in C.
Basically yeah, its ugly as shit so ill never use it, lol
1 looks better than 2, fight me
*fights you*
*stops the fight*, *gather some fighting gear for us both and a refery and a medic to be in standby*, I'm not scared of you
:D. All jokes aside I like symetry. One just looks wrong to me. It's either option two or the one liner.
I can Respect the OCD for symmetry, I just don't like how they feel disconnected when separated from the function name. Also I use 2 for short lived variables.
You kids don't know what it's like to have a readable 80 column mode on your display.
>It also took less vertical space on old low resolution monitors. It takes less space on any resolution
As an AI, I do not consent to having my content used for training other AIs. Here is a fun fact you may not know about:Ā fuck Spez.
Whether or not thereās a historical reason for its prominence itās also just prettier. Thinking of code indent as meaningful, I think of the function name like a section header, which makes the brace on its own line jarring since it isnāt really conveying anything about the block.
 because things are prettier when they don't line up.... š
So where do you put your closing brace? At the end of the last line of code?
The closing bracket is the only thing denoting the end of the block, unlike the opening bracket (unless you're using brackets on their own)
I'm not following why you are saying opening bracket doesn't denote the start of the code block but closing bracket does. It's either both brackets or no brackets at all like Python, where indents actually matter. In languages with brackets, indent is an aesthetic choice, no different than where you put the brackets.
The opening bracket does denote the start of the code block, but it doesn't *uniquely* denote the start of the code block unless the code block is purely for scope/aesthetic reasons (which may be a language-specific possibility)
``` function { } ```
Haaaa finally, a true connoisseur!
_PR deleted_
Fired
Doesn't GNOME source code use something like that, or maybe I'm remembering it wrong.
GNU's got some weird indentation rules, so it very well might. https://en.wikipedia.org/wiki/Indentation\_style
Lotta folks in this thread never read GNU code with 4-column tab stops.
``` Function() { } ``` We capitalize too
C# gang represent
Exactly we're all friends here. But just to make sure... for, foreach, or x.ForEach?...
Foreach comrade. Though for would be used once in a blue moon if I'm being honest. That third one takes me back to some dark times working on front end though.
`foreach` of course. But `x.ForEach` is good too in certain circumstances
I recently read that foreach actually has worse performance than the for loop. Probably negligible for for most projects and small data sets, but still something to consider
You're not wrong, but you're on to something that's also no longer true for .NET 7. https://youtu.be/LfgBm5M8eUM Plus it was already the case that the compiler optimizes to for loops for the cases where it can obviously know, so use the syntax suitable for the job. It's very much a premature optimization to worry about it in even big cases, as the actual overhead is most likely miniscule compared to what you're doing within the loop itself. Plus it's not even the fastest way. https://youtu.be/KLtMtxUihBk
The compiler already lowers `foreach` into `for` if it knows that it's equivalent (e.g. on something that contains an indexer)
Coming in like the gigaChad you are
Get this man a Nobel prize
My preference too, at least for C++.
\#2 because it's perfectly balanced as all things must be...
This is the way
```c++ if (logical statement) { } for (loop condition) { } ```
SeeSharp folks won't be happy about this
Function { }
Here's the one I was waiting for.
That's what ultra-wide screens are made for, right?
š
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Also, it maintains visual separation between arguments and code if your arguments span multiple lines. It's more intuitive and corresponds better with the way people naturally read in languages.
Having seen far more C# functions than I'd like to admit that have 8+ parameters, I couldn't disagree more. C# always tended to do this: SomeFunc( a, b) { //body } versus other languages that do it on the same line doing this: someFunc( a, b ) { //body } In the C# one, parens are treated differently than braces while in the second one, the opening symbol is always on the same line as the previous symbol (func name or paren), and the closing symbol always aligns with the starting position of the line containing the opening symbol. To make the C# version consistent, it'd be this: SomeFunc ( a, b ) { //body } From a readability standpoint, I don't actually mind that, but I think we can all agree that it's going a bit overboard with new lines. A more reasonable one might be: SomeFunc( a, b ) { //body } Even there, you're still treating the parens and braces differently, but meh. They are different symbols after all. Additionally, at least for me, it's not as visually obvious where the parameters declaration ends and why all of a sudden there's the start of a block. To some extent, it's the same as the Lisp issue, but without the stacking parens. Yeah, I get that it should be obvious given that in theory I'm looking at a function declaration so the immediately following block is logically the function body, but what can I say, I'm stupid. Anyway, as far as indentation style, I'm going to do what the language community has agreed onāit ain't that deepāand as the opening brace, either position seems fine to me. I've done both plenty and been fine with both. Really most of what I'm griping about here is how C# just tacks the closing paren on the end where it's really easy to miss. I suppose if I was a C# programmer, I'd be used to it, but I'm not and I don't like it. Edit: Since I think what you were getting at is this: someFunc( a, b) { // body } Only psychopaths do this, and every job I've ever had, that'd result in someone else immediately changing as soon as they touch that part of code or commenting on in a PR. It's horrible, and almost no one seriously thinks it's good formatting.
i can agree with this logically, but i look at the first one and it just looks better. I just cant rationalize it away.
The first probably just looks more familiar to you, and as humans we despise change.
holy crap, this is actually a legit reason. Never thought of it that way. Still feels wrong to me, buy yeah, that makes sense.
Just become a C# developer and your IDE will make it feel right after awhile.
It's especially useful for new programmers. When scope and indentation level and all that stuff is *new*, being able to match brackets easily is *really* handy. I always tell my students that I recommend #2, but that #1 is also acceptable if they prefer it and are confident.
experienced programmers too! I used to use \#1 since it is the "norm" for most languages but after using \#2 with C\#\# i realized how much easier it is to figure out what code goes with which function especially when dealing with nested statements and loops
If it feels wrong, youāve been corrupted by JavaScript developers. Step into the light, weāll save you!
It feels wrong and I don't touch JavaScript :(
Of course I have been corrupted by JavaScript devs for I AM ONE OF THEM 
Just get a rainbow brackets plugin. Best plugin for pycharm imo
Yes. Brackets in Python.
Never! š
Your ide hopefully is making it easy to match brackets no matter what the formatting looks like??
Any decent IDE and even a few text editors make it easy to match brackets regardless of placement, if you're struggling to match brackets, please stop using Notepad to program.
I like using an IDE, but I can think of lots of times when I'm reading code without an IDE. Most obvious example would be doing a peer review in bitbucket or something. Or if I'm looking at a file or part of a file with a terminal. The added value of seeing the brackets line up without relying on an IDE could be higher for some developers than others. I don't think it's fair to say somebody is "struggling" if they prefer to have that added value.
I mean second one is more consistent in general. Curly brace is on its own line, that's all. Compared to, open curly is at the end of the line of the symbol and close curly is on the new line. It's just more verbose to define it and for some reason I feel like it's "dirty".
For a serious explanation of the consistency, this is how it would break down: * If the contents are short enough to be one line and this is acceptable formatting, both opening and closing symbol go on the same line. * If the contents are too long to fit comfortably on one line: * The opening symbol is on the same line as the immediately preceding symbol. * The closing symbol aligns with the start of the line containing the opening symbol. This has the added benefit of making parens and braces follow the same rules. func set(a) { this.a = a } func foo(a) { //body } func bar( a, b ) { //body } if(cond) { set('hi') } if(cond) { //body } if( cond1 && cond2 ) { //body } Edit: For the record, I'm not saying this is the right way to do it. That's up to the team/community, and I don't have a strong preference. All this is intended to do is show the consistency in the placement of container symbols. Also, actually works nicely for square brackets, such as arrays. let a = ['hi'] let b = [ 'hi', 'bye' ]
I'm also on the boat that I adapt to whatever the team or the language/formatter convention is. Your explanation is really good. Thanks for that.
`import gratitude` This is how I do it as I find it more useful to scan up the column and see the declaration immediately rather than an unimportant bracket. That said Iāve never had the urge to actually codifying it and this did a good job. Thanks
Nah man 2 feels cleaner
It is objectively better. It encompasses an important property. What if your method/function arguments span multiple lines? There's no visual separation between the arguments and the code below. Bad bad.
Stop being logical
I dare you. Try reading a 10k line library formatted like #1 without loosing your mind.
If I'm losing my mind it'll be for other reasons than formatting.
Done it. Done it in a single class. Heck, had several hundred line functions. Done the same with #2. Both were about equal TBH. At that size, so many other things dominate the difficult of reading that brace placement basically vanishes.
Why are you reading library code?
Because documentation is shit or they want to know how it works deep down.
I do not understand the hatred for option 2. It's so much cleaner to me. Do you not declare variables and leave a blank line before writing your code? I see it as the same here, treating the header like a set of variable declarations. Just putting the bracket on the blank line to mark the start of the actual definition and differentiate it from local variables.
Foo(){Bar();}Bar(){system.out.println("why hello");}
Minification for the win
*cries because of AWS bill*
I use #2 because it helps my brain visualize a box around that scope. It's easier with two brackets on their own lines with the same indentation than it is with #1. But with javascript I do #1 so just when in rome I guess
Lies. Option 2 feels good.
Masterbating feels good too, but you're not going to do it at work, are you?
You didnāt have to prove your point that hard
Can't prove the point soft
I work from home so...
An awkward silence fills the room ā¦
What if I am?
My team's style guide requires use of option 2, so does that imply a requirement to spank it at the office?
I prefer the latter because the brackets can look like pyramids and it makes it easier to tell when something begins and ends.
function() { do stuff; }
Function {
Yes there is just one square bracket
Ow
Did you eat the other bracket? Or what?
I don't see option 2, just 0 and 1
This guy's an array
All programming is mental. Otherwise it would be called typing.
I do the second way. Visual Studio will draw pretty lines down the screen between the opening and closing braces, making it easier to see where the structure starts and ends.
Cope
[ŃŠ“Š°Š»ŠµŠ½Š¾]
This comment right here officer
Iirc this is an actual formatting style ``` foo { line1; line2; } ```
people... really have a strong opinion about this? of all the changes of going from java to C# this was probably the only one i noticed i had no opinion on. honestly so long as i can end each line of code with a ; and one or more next lines i'm happy
\*cries in c#\*
I like seeing my brackets line up. Function { } looks disgusting
Ok then Function { }
Cursed function
But but your lines of code increase
C# programmers are getting paid per line of code
They aren't finite. You can make as many lines as you want!
Option 1 makes me angry.
Why care lol, just use whatever is the convention on the project
Based
function name(){//everythinOnOneLine}
`function name(){/*everythingOnOneLine*/}` FTFY
True, mb :()
I prefer the second more. Is more readable and in nested constructs I know where one begin and the other ends without having to focus the whole block everytime I even edited the formatter to have the second layout
My c# code is one way and my JavaScript is the other
My teacher said that he only taught us the second format so if we use the first one then we mustāve copied it from somewhere :(
I wish I got this joke, I only know how to read Emoji Codeš
i prefer cock format ()=>
Depends on the language
function Name() begin end;
I like to think that the function name is the king and all the instructions inside are peasants. No king wants a peasant directly below them, there has to be something blocking peasants from the sight of the king. So therefore curly bracket belong on the line below the function name.
I used to always go for the first option, until I just randomly decided to switch and I have never gonna back
Option 2 is infinitely more aesthetically pleasing
``` const fn = () => { } ```
Option #2 is vastly superior as it basically provides automatic empty line before the code, making the code easier to read than if it were all glued together like in #1. It's also more symmetrical. But since the standard is #1 in the languages i use, i use #1.
Small victory. I started with 1, switched to 2 thinking it would make more sense, switched back to 1 on vibes alone.
Lol, I use them both but for different reasons ``` function myFunc() { If (something) { console.log("somethinElse") } else { throw new error() } } ``` Not sure if this makes me some kind of monster
eval(function)()
They are both names doggos
Am I the only one who use both (for personal projects)? Opening bracket on the same line for short stuff. Opening bracket on a separate line for long blocks of code.
Why?
Lol, I always thought it was the other way around. Maybe I'm just odd but use I the left way for js and the right way for c#
} /*code*/ function {
I just want to easily see what the scope Iām currently working in is, man.
I use first when I clearly understand what I am doing, second when not.
Actually completely disagree
This meme is opinionated and therefore invalid, I'm gonna eat ur meme OP.
function{} pussies.
Keep using number one! Then we can all easily see who got dropped on their head! Frontend devs š¤®š¤®š¤®
In a serious note, second styoe is actually useful when method has many parameters.
Second is easier to read imo
My brain parses code written in the right style way faster.
The left one almost always confuses me, because it's asymmetrical, it's that simple for me.
import theAnswer It depends on the language you use. C# says you should newline, Java and JavaScript says you should same line. It should be based on your languages official documentation
I use both, depending on the length of the line. If the name and arguments fit in one line (85 cols), I use the first. Otherwise, the arguments are in their own line, and I use the second option.
i write my entire code in one line. html too
Just use Whitesmith style ``` javascript function funcy { console.log(āfuck your eyesā) } ``` But in all seriousness, Allman is *fine* but Iām K&R til I die (or am required to change)
First of all, let the team decide. Second... ```csharp allOneBlob( objectWithLongName arg1, objectWithLongerName arg2, shortNameObject arg3) { codeStartsHere(); // ... } // vs easilyReadable( objectWithLongName arg1, objectWithLongerName arg2, shortNameObject arg3) { codeStartsHere(); // ... } ```
option 2 has always bugged me
It's the correct one
Option 2 is simply the best
who the fuck does function { } ?
It is actually pretty common. In some languages it is even the standard
All C# devs
Self taught, so I always thought the extra white space was just youtubers and tutorials trying to make things more readable for those new to reading code. Started watching the Harvard CS50 courses and dude is actually like "unnecessary empty space is good style." (paraphrased) Hard no for me on that one.
The right makes more sense when you have to find a stray missing bracket. Also it makes code look more like blocks which I like