Pet Peeve
-
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(); -
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>Mladen Janković wrote:
it can make you look obnoxious.
But I am obnoxious
-
oh dear lord :laugh: :laugh: :laugh:
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L %^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2 W_AD`EPABIKRDFVS)EVLQK)JKQUFK[M`UKs*$GwU#QDXBER@CBN% R0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
----------------------------------------------- 128 bit encrypted signature, crack if you can
-
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();I prefer
if (something) DoAB();
for the latter. I never use it, but have recently come across it. It seems more readable to me.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
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:
If both branches are a single line, I prefer the second. However, I've seen too much of this abomination:
if (condition)
{
DoThis();
DoSomethingElse();
}
else
DoThat();Curvature of the Mind now with 3D
-
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();
}
}Your automated tests should prevent a subtle bug even making it into the testing environment.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
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!
Hear hear.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
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!
The rule that I have is that you omit the braces iff the statement is a simple single line. Also, if either branch needs braces then both get them, and loops always have braces.
Curvature of the Mind now with 3D
-
The rule that I have is that you omit the braces iff the statement is a simple single line. Also, if either branch needs braces then both get them, and loops always have braces.
Curvature of the Mind now with 3D
but that's the start of the problem! someday, someone is going to have to come along and add some more logic in that if, and you've just forced them to do the work you should've done the first time! IMO
-
but that's the start of the problem! someday, someone is going to have to come along and add some more logic in that if, and you've just forced them to do the work you should've done the first time! IMO
I understand your point of view, but still prefer my way of doing things. What I find more troubling is that after working on a bunch of javascript, I'm starting to prefer the old school C style brace layout.
Curvature of the Mind now with 3D
-
I prefer
if (something) DoAB();
for the latter. I never use it, but have recently come across it. It seems more readable to me.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
I don't do if() and the code in the same line. It is more a debug stuff. If I want to debug the if itself I put the breakpoint in that line. If I only want to debug the method call, after the if succeeded, I put the breakpoint in the call line.
