|
That is the style I use except the closing brace closes below the opening keyword. I find the lone brace usually helps me to easily find where the braced sections end easily. Though for procedures with a lot of conditions, at the end the braces tend to run together.
I also only use two spaces per indent. It saves a lot of horizontal space.
void someFunction() {
if (something) {
DoThings();
}
else {
DoDifferentThing();
}
}
|
|
|
|
|
If it works for you, good! I used it in the past, until the logic of all indents being at their own level became clear o me.
|
|
|
|
|
Another offshoot of the brace wars.
|
|
|
|
|
trønderen wrote: But with the modern style of always putting braces on separate lines, always put braces around even a simple assignment if it is e.g. an if clause (so the minimum number of lines for an if statement is 4). Some people even insist on always putting blank lines before and after any 'structured' statement (such as if/else, loops etc.),
Yup. It's a code style I enforce with everyone I work with. It makes stuff a lot more readable.
If seen crap like this:
some very long long of code
if (foo == null) return;
another very long line of code
And I've completely missed the return, not to mention that there should always be a single point of return. Code should be readable and organized, and blank lines is the best way to do that given the tools we have.
Now, personally, I don't think higher level functions should ever even have code in them except to call lower level functions. But trying to enforce that behavior on people (including myself often enough) is asking too much.
My 2c!
|
|
|
|
|
Marc Clifton wrote: there should always be a single point of return
that is debatable, IMHO.
I like to fail fast. fail early. which is ReSharper's default setting. return now and not 25 lines of code later.
Another dev I work with likes to have one return statement for everything, just like you.
I also like to reduce nesting If statements. Some devs love 50,000 nested If statements. No thank you.
|
|
|
|
|
Slacker007 wrote: Marc Clifton wrote:there should always be a single point of return
I can accept your principle, but honestly: I do not really see the advantage of coding 'goto returnfromfunction' rather than 'return' (obviously, there is then a 'returnfromfunction' label at the end of the function). If you do not recognize the 'return', then why would you more easily recognize 'goto returnfromfunction'?
This is probably related to
Slacker007 wrote: I also like to reduce nesting If statements. Some devs love 50,000 nested If statements. No thank you.
Way back in my student days, there was an article in one of the ACM publications, it may have been Communications, but more likely SIGPlan Notices, entitled "The rightward migration of source code", discussing the consequences of without question accepting such dogmas as 'single point of return'.
The consequences of 'single point of return' may depend strongly on which other coding 'rules' are enforced. I have frequently seen 'single exit point' together with 'break out of loops is forbidden'. So if you detect a fatal error at iteration 2 of a 100 iteration loop, you cannot terminate, but must set an error flag, tested in every one of the subsequent 98 iterations in a 'if (!errorterminate) ...
If 'break' is forbidden, so you are not allowed to write a 'do {} while (false);' with, say, every parameter check either continues, or breaks out, then you cold cause the exit, say, on an invalid parameter, by creating such a one-iteration loop, with an exception handler. Sometimes, managers who strongly object to break statements willingly accept raise statements.
Of course this makes next to zero sense. But lots of programmers who dislike explicit statements seem to fully accept exception handling to do the same thing. One obvious magic - the break or return - is forbidden, while something obscure, handled independently from each side, is fully accepted. I do not see why.
Like Slacker007, I fight rightward migration. Allowing multiple return points is part of the fight.
|
|
|
|
|
Multiple returns are syntactic sugar for goto.
|
|
|
|
|
I have learned to agree with you on that. In the old days, I was taught that you write
int f(MyObject obj)
{
int result = 0;
MyObject2 obj2 = obj.FunctionA();
if (obj2 != null)
{
MyObject3 obj3 = obj2.FunctionB();
if (obj3 != null)
{
MyObject4 obj4 = obj3.FunctionC();
if (obj4 != null)
{
result = obj4.value;
}
}
}
return result;
}
Now I find it easier to understand when I write
int f(MyObject obj)
{
MyObject2 obj2 = obj.FunctionA();
if (null == obj2)
{
return 0;
}
MyObject3 obj3 = obj2.FunctionB();
if (null == obj3)
{
return 0;
}
MyObject4 obj4 = obj3.FunctionC();
if (obj4 != null)
{
return 0;
}
result = obj4.value;
}
This is easier to understand than having the code march off the right side of the page and removes exceptions to normal processing early on without cluttering the main part of the code. Since I write software application applications, I'm normally have these types of code where
|
|
|
|
|
Now I have a better understanding of the reasoning behind the brace wars back in the old C days. Whether to place the opening brace on the same line as the if/for/while/switch/function or on the next line. Most were of the next line camp and preferred it to make the code look more elegant and increase the lines of code. And also, it looked good if you had a 'pretty printer' utility for your code. But, when only having 25 lines per screen, that was limiting, and you wanted you screen real estate to be populated with meaningful lines of code rather than entry and exit braces fluff.
|
|
|
|
|
A lot of the recent changes in the C# language seem to be syntactic sugar. It's nice when writing code, but it's another bit of shorthand my poor old brain has to translate to the long form before I understand what the code is doing.
Software Zen: delete this;
|
|
|
|
|
IMHO, its all in an effort to write 25,000 lines of code in one line of code, using this magical voodoo syntax.
readability? sure, if you are Satan and can read the ancient angelic scripts.
|
|
|
|
|
Agreed!
And we all know too much sugar is bad for you.... 
|
|
|
|
|
I would prefer the second option. Back when I was in school, we were taught that we should not initialize variables in single line to improve readability. Somehow that has stuck until now. I do not see any gain from writing code perspective in option 1. I could have a wrong order and mess things up if arguments are of same datatype. In multiline set up I feel I am less prone to make that mistake.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Two rules of programming:
1: Use a ton of free, poorly maintained libraries because they're free and solve trivial non-problems so that bugs can be introduced every time you upgrade one block in the jenga tower you've written.
2: Use interfaces, inheritance, partial classes, asynchronous programming and lambda expressions to solve trivial problems so the code cannot be read in a single pass.
The worst person on your team is the guy who is always finding new and cool stuff.
He's an ass. Fire him now.
|
|
|
|
|
I'd triple up-tick your comment if I could.
|
|
|
|
|
I have a very, very simple rule: I want to be able to read AND understand both the intent and method of a piece of code in a few minutes.
Anything less than that causes confusion and errors. And I'm getting to old and cranky to waste time looking at undecipherable code.
|
|
|
|
|
Trying to evolve to TypeScript constructors?
I do not see where it saves any typing in the current form. If an IDE gives you that as a default completion where you do not need to type anything, then I could see accepting it.
Less clear to my old eye as well.
|
|
|
|
|
I kind of like it in this case! If you're only assigning things passed in via the constructor I don't see a ton of value in spacing things out.
But I think it's a matter of using expression bodies in the right place and not overdoing it. I often see Visual Studio suggesting I switch to an expression body and when I try it, the code ends up uglier. I think they're useful when they enhance readability, for example in indexers or property getters and setters:
public string this[int i]
{
get => types[i];
set => types[i] = value;
}
or
public string Name
{
get => locationName;
set => locationName = value;
}
|
|
|
|
|
I'm hoping it not a long term trend, or the debugging tools have to get better.
I can put a break on a function and inspect the variables as I step through the code, it gets a little trickier on expression bodies especially when working with large collections or arrays 
I like the cleanliness of expression bodies, but at the same time sub expressions do tend to muddy up the readability.
Someone correct me if I'm mistaken, but once the code is compiled a expression body just gets translated into a function (like) code structure which is just a jump to address and then return as seen by the processer. I'll admit I've not looked into what happens too much under the hood with expression bodies in dotnet.
|
|
|
|
|
Pest = nuisance
losing a point = is
Nuance = variation
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Well, that explains why I didn't get it ... well done!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I was beginning to think everyone was offline 
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Not in my case, just my IQ ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
pkfox wrote: losing a point = is
That bit's got me beat!
|
|
|
|
|
losing (get rid of)
a I
point S
I only got it after the solution was published as well.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
