Pet Peeve
-
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.
-
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.
This is true. I always use separate lines for everything myself, but all I was saying is I find
if (if stuff) [then stuff];on one line more readable, in established and (hopefully) debugged code. If I have to debug it myself, I just hit enter and add a breakpoint on the new line. Then use the "source control undo" in solution explorer to revert back to the prior pristine state.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 there's only one "do", the whole thing should be on one line. The reason the blocks were introduced is because multiple "do"s on one line are hard to read, so insisting that a single "do" be in a block is taking the idea in the wrong direction.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Personally, for one line this-or-that...
condition.IfTrue(()=>DoThis()).Else(()=>DoThat());;P MarcImperative to Functional Programming Succinctly Higher Order Programming
Yes, I am sure for your disciples that's a very good thing :)
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. » Alan Kay's clarification on what he meant by the term "Object" in "Object-Oriented Programming."
-
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:
Perhaps best to blame the language designers for allowing such freedom ? I'm with Chris L. and others who point out we're no longer in the age of fewer-characters-are-best-because-memory's-so-precious that we can't afford white-space, or beaucoup de braces. C# code that looks like VB has the smell of sewage to me (note: I do not "hate" VB).
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. » Alan Kay's clarification on what he meant by the term "Object" in "Object-Oriented Programming."
-
This is true. I always use separate lines for everything myself, but all I was saying is I find
if (if stuff) [then stuff];on one line more readable, in established and (hopefully) debugged code. If I have to debug it myself, I just hit enter and add a breakpoint on the new line. Then use the "source control undo" in solution explorer to revert back to the prior pristine state.No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
I understand... and I can't say I disagree... that arrives to the point of preference, not to the point of usefulness. But one thing I never do is 2 (or more) real calls in the same line: SomeObject.DoCallOne().DoCall2(otherObject.AnotherCallWithAResult(), evenAnotherObject.WithEvenAnExtraCall(), theFinal.ObjectWithTheFinalCall());
-
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:
They think, If we write that way then our system will be heavy as each character has some byte. :) :) :) :-D
-
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:
How would you feel about
condition ? DoThis() : DoThat();
?
My plan is to live forever ... so far so good
-
How would you feel about
condition ? DoThis() : DoThat();
?
My plan is to live forever ... so far so good
condition
? DoThis()
: DoThat();And now? All in all none of this really matters. As long as everyone on the project sticks to a predetermined coding standard, then the format doesn't matter as much, as long as its consistent. Consistency in code can resolve a huge amount of misunderstanding.
-
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:
-
condition
? DoThis()
: DoThat();And now? All in all none of this really matters. As long as everyone on the project sticks to a predetermined coding standard, then the format doesn't matter as much, as long as its consistent. Consistency in code can resolve a huge amount of misunderstanding.
Standard? STANDARD? What's that??? I found that we do keep to standards whenever all the other developers code exactly the same way as I do. ;P
My plan is to live forever ... so far so good
-
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)Totally agree...but for a very spesific reason. I'm using a Braille display with a maximum of 40 chars per line, so it have a influence on my format preferences... ;P Seriously though, if (condition) { Action1(); } else { Action2(); } is my real preference, and there's a plus to that, whenever the situation change to have more than one statement for the if test, the person who has to change it doesn't have to remember to go and fill in the {}.:cool:
-
I understand... and I can't say I disagree... that arrives to the point of preference, not to the point of usefulness. But one thing I never do is 2 (or more) real calls in the same line: SomeObject.DoCallOne().DoCall2(otherObject.AnotherCallWithAResult(), evenAnotherObject.WithEvenAnExtraCall(), theFinal.ObjectWithTheFinalCall());
Just your contrived example hurts my eyes. I'd hate to see that in real life. :~
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
