Pet Peeve
-
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.
-
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.
