Pet Peeve
-
Heathen! Blasphemer! How do you even know that VB uses braces???
Ha. Well you see... I work for the devil, but it's only because I'm evil.
Jeremy Falcon
-
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}as opposed to:
if (condition)
DoThis();
else
DoThat();Pedants :sigh:
IMHO the latter is easier to read. I've recently had to resort to cheap reading glasses as { started looking like (! (even at 125%} :laugh: I don't always use {}, but when I do, I also prefer then on their own lines for readability. :thumbsup:
"Go forth into the source" - Neal Morse
-
That's not good enough...
if
(
condition
)
{
this
.
DoThis
(
)
;
}
else
{
this
.
DoThat
(
)
;
}It's not properly formatted until there's only one token per line. :)
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)if (condition) { this.DoThis(); } else { this.DoThat(); }
You probably meant
Ian Shlasko wrote:
It's not properly formatted until there's only one token per line in the entire application.
I guess it's theoretically possible... :~
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
Chris, you can't BS me, come on man. You honestly expect me to buy that not using brackets for a single-line if condition makes code harder to maintain? Seriously? Where's the joke icon?
Jeremy Falcon
Sure it's easy, until another developer adds a second line and forgets to add brackets. I've been working in some source code that didn't use brackets for single statements. I introduced a few bugs by not adding them when I had to and I've been wondering more than once if the original developer REALLY meant not to add brackets....
if (condition)
DoThis();
else
DoThat();
DoAnotherThing();is really weird to look at and at the very least makes you wonder if it was intended... Especially if
DoAnotherThing();isn't properly in/outdented!public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
Sure it's easy, until another developer adds a second line and forgets to add brackets. I've been working in some source code that didn't use brackets for single statements. I introduced a few bugs by not adding them when I had to and I've been wondering more than once if the original developer REALLY meant not to add brackets....
if (condition)
DoThis();
else
DoThat();
DoAnotherThing();is really weird to look at and at the very least makes you wonder if it was intended... Especially if
DoAnotherThing();isn't properly in/outdented!public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}Ok, you have a good point with that, but it's still not worth the trade off of having really extra long files / routines. Besides, it gives you something to spot the new guys with so you can give them a hard time.
Jeremy Falcon
-
IMHO the latter is easier to read. I've recently had to resort to cheap reading glasses as { started looking like (! (even at 125%} :laugh: I don't always use {}, but when I do, I also prefer then on their own lines for readability. :thumbsup:
"Go forth into the source" - Neal Morse
-
Ok, you have a good point with that, but it's still not worth the trade off of having really extra long files / routines. Besides, it gives you something to spot the new guys with so you can give them a hard time.
Jeremy Falcon
Jeremy Falcon wrote:
it's still not worth the trade off of having really extra long files / routines
It's really very much worth it. Look at it this way, if (it prevents a subtle bug from going into production (and dependent on your internal processes that chance may be a considerable risk)) { you may have saved that company downtime or wrong data and dependent on the size of that company a whole lot of money! } else { you just scroll a bit extra (it's negligable) and no one gets hurt... }
Jeremy Falcon wrote:
so you can give them a hard time.
If the new guy screws up I'm the one responsible and I can get to fix whatever he broke, so that joke's on me ;)
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
Jeremy Falcon wrote:
it's still not worth the trade off of having really extra long files / routines
It's really very much worth it. Look at it this way, if (it prevents a subtle bug from going into production (and dependent on your internal processes that chance may be a considerable risk)) { you may have saved that company downtime or wrong data and dependent on the size of that company a whole lot of money! } else { you just scroll a bit extra (it's negligable) and no one gets hurt... }
Jeremy Falcon wrote:
so you can give them a hard time.
If the new guy screws up I'm the one responsible and I can get to fix whatever he broke, so that joke's on me ;)
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
-
if (condition) { this.DoThis(); } else { this.DoThat(); }
You probably meant
Ian Shlasko wrote:
It's not properly formatted until there's only one token per line in the entire application.
I guess it's theoretically possible... :~
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}Way back in my College days the Software Lecturer told us (the class) it wasn't possible to do the above. I proved her wrong by writing a short Pascal (I think) program with no returns all on one line, ah Youth :)
-
Way back in my College days the Software Lecturer told us (the class) it wasn't possible to do the above. I proved her wrong by writing a short Pascal (I think) program with no returns all on one line, ah Youth :)
The end of the story - "...and that's how I got to repeat introduction to programming!!"
Quad skating his way through the world since the early 80's... Booger Mobile - My bright green 1964 Ford Falcon - check out the blog here!! | If you feel generous - make a donation to Camp Quality!!
-
Chris, you can't BS me, come on man. You honestly expect me to buy that not using brackets for a single-line if condition makes code harder to maintain? Seriously? Where's the joke icon?
Jeremy Falcon
it certainly is harder to maintain. i can't count how many times i've had to fix something in code that only uses brackets when one or more statements are being controlled. so you get stuff like:
for (i=0;i<10;i++)
for (x=0;x<10;x++)
if (xyz) foo()
else for (z=0;z<10;z++)
bazinga();
bar();and then you have to spend precious brain wattage figuring out that bar(); has nothing to do with any of the rest of it. this isn't 1967, 3 bytes for a bracket and an CR/NL isn't going to run you out of punch cards. make the code readable!
-
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}as opposed to:
if (condition)
DoThis();
else
DoThat();Pedants :sigh:
The decision which to use is simple: - follow the coding standard - if you don't have it, use whichever style is used in file/project - new project/file, use whatever you find more atheistically pleasing to you Personal atheistic preference is one of very few arguments that I can accept as valid in this "debate" (like in any other debate on any kind of style). The only argument that is supported by concrete numbers is saved on-screen space by the second style. All other arguments are largely unsubstantiated (maybe I'm wrong, but let me see some numbers) So don't go around calling people lazy just because they don't conform to your preference, it can make you look obnoxious. <edit> My preference:
?:. What' you gonna do now? <edit> -
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}as opposed to:
if (condition)
DoThis();
else
DoThat();Pedants :sigh:
-
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}as opposed to:
if (condition)
DoThis();
else
DoThat();Pedants :sigh:
I am not lazy (well, I may be, but that's not the point) and the reason I prefer the latter is to reduce the noise. Less noise, more readability.
-
Why are people so lazy? For example, how hard is it to
if (condition)
{
DoThis();
}
else
{
DoThat();
}as opposed to:
if (condition)
DoThis();
else
DoThat();Pedants :sigh:
Personally, for one line this-or-that...
condition.IfTrue(()=>DoThis()).Else(()=>DoThat());;P MarcImperative to Functional Programming Succinctly Higher Order Programming
-
Way back in my College days the Software Lecturer told us (the class) it wasn't possible to do the above. I proved her wrong by writing a short Pascal (I think) program with no returns all on one line, ah Youth :)
:thumbsup: Quite. The maturity of a programming language may (in part) be calculated by how many newlines are required. A proper language requires none.
-
-
The decision which to use is simple: - follow the coding standard - if you don't have it, use whichever style is used in file/project - new project/file, use whatever you find more atheistically pleasing to you Personal atheistic preference is one of very few arguments that I can accept as valid in this "debate" (like in any other debate on any kind of style). The only argument that is supported by concrete numbers is saved on-screen space by the second style. All other arguments are largely unsubstantiated (maybe I'm wrong, but let me see some numbers) So don't go around calling people lazy just because they don't conform to your preference, it can make you look obnoxious. <edit> My preference:
?:. What' you gonna do now? <edit> -
I know what you're saying; however, there are times I find the second one easier to read. For example, if I have several of those on a page the extra symbols spread stuff out. I still do it the first way, but there are times when the second is easier for me to read.
I agree with you. And I am actually the kind of person that when has to modify something like:
if (something)
{
DoA();
DoB();
}To only call a DoAB(), I will go there and kill the extra { and }. So, I have more work doing that, but I keep consistency. So, it becomes:
if (something)
DoAB();
