|
But It's upcoming very very close 
|
|
|
|
|
Yeah. I will party like it is nineteen nigthy nine. You welcome, but need sign a waiver.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Merry Christmas, all the best for the New Year 
|
|
|
|
|
very Merry Christmas, and You too.
|
|
|
|
|
Right back at you! 
Moist Von Lipwig
|
|
|
|
|
For the Three Wise Men: "Oh Camel Ye Faithful"
"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!
|
|
|
|
|
Tom Lehrer suggested:
Given that the true spirit of modern Christmas is the commercial spirit, perhaps Christmas carols should be updated as follows:
- God rest ye merry merchants, may ye make the yuletide pay
- Angels we have heard on high, tell us to go out and buy
- Hark, The Herald Tribune sings, advertising wondrous things
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I'm browsing through the labyrinth of MSDN and I am seeing more and more use of expression bodies.
eg
public MyObject(string name, string data) =>
(_name, _data) = (name, data);
as opposed to
public MyObject(string name, string data)
{
_name = name;
_data= data;
}
This makes me feel old because it reminds me of when we used to cram our code into as small a space as possible to handle 25 line screens.
Maybe this is like skinny jeans: in a year's time it'll all be over.
cheers
Chris Maunder
|
|
|
|
|
And 80 (or possibly 132) columns. I still use vi & emacs for programming, but always use 132 column mode. I still run into line-wrap on a regular basis. My colleague still prefers 80 column mode - we are dinosaurs, after all - and I have to confess I have no idea how he puts up with it.
Keep Calm and Carry On
|
|
|
|
|
k5054 wrote: And 80 (or possibly 132) columns.
At work, we were developing a new company C coding standard. One of the proposals was to limit source code lines to 80 cols. Our project manager immediately declared that he would grant an unconditional exemption to that rule: We had rules for how to name #define constants that lead to identifiers exceeding 80 chars. So the 'max 80 col lines' did not make it into the standard.
We retained the rules for how to name #define constants. Many times later, I have questioned whether we retained the right rules. Maybe we should have accepted 'max 80 col' and rather revised the naming rules.
|
|
|
|
|
You got some kind of issue with integerToCountFromOneToOneHundredInForLoopInIfMyValueIsTrueBranckOfMethodFooOfObjectBarInClassBas? I suppose you think it should have been called i or something, you Philistine!
|
|
|
|
|
Change for just "Change's sake is never a good thing.
If there is a legitimate reason, then OK.
Old guys don't die, they just fade away...
|
|
|
|
|
I do not know C# and never tried to use it but, if they were going to change their parser to accommodate a new syntax, they could have gone the extra mile and do something inline like
public MyObject(string name=>_name, string data=>_data){}
I have been secretly wishing for something similar for constructors in C++. Example
MyObject(std::string name=defaultName:_name, std::string data=defaultData:_data){}
instead of what we have now
MyObject(std::string name=defaultName, std::string data=defaultData):_name(name),_data(data){}
There would be less typing.
Or go a little further and allow for static functions to be called to evaluate values. Example
MyObject(std::string name=evalName():_name, std::string data=evalData():_data){}where "evalName()" and "evalData()" would be automatically passed the given parameter value. The signature would be
std::string evalName(std::string name)
|
|
|
|
|
Chris Maunder wrote: This makes me feel old because it reminds me of when we used to cram our code into as small a space as possible to handle 25 line screens.
I do appreciate fitting an entire function/method on the screen, especially when I didn't write the code myself (or I wrote it so long ago that I no longer remember my line of thought), and need to read the code forwards and backwards and from both sides to understand the logic.
With the 60+ line editor windows of today, you'd think that was a modes request. 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.), making 5 (or even 6, depending on context) the minimum line count for a simple 'if' ... Then you certainly won't be able to fit any large fraction of real-life methods in a 60 line editor window, or the hardcopy equivalent: One printed page. If you also forbid end-of-line comments, requiring comment to have their own lines (this has been the case in the majority of projects I have worked on, you frequently see 60 line windows "crammed with code" (according to the coding standard, but really containing no more than 5-8 statements.
When I write code independent of such spacing requirements, I succeed in fitting maybe half of the function bodies below 60 lines. Then I e.g. put the opening brace at the end of the first line, and I accept un-braced single assignments as if/else clauses, following the condition or the 'else' keyword on the same line. A short (typical: half line) comment is written from col 70 of the line to which it applies, or col 90 if many source lines are long - I want the option to 'semi-ignore' the comments; when I know the code, comments should be there, but no clutter up the actual code statements.
If I want people to review code written this style, I may print it double spaced (today, when most code reviews are made on-screen, I can just replace every newline with two newlines), to give other developers something in that 'airy' style that they want. No one ever remarks anything about blank lines around all statements, not just structured ones. That makes every statement clearly defined. It is considered making the code 'easier to read' (just like children's books usually has significantly larger line spacing than books for adults).
I knew one guy who was almost totally blind, yet an eager program developer. He read (and edited) the source code on a braille line: With his fingertips, he could read one line at a time, scrolling up and down a line at a time. He sort of kept the entire source code inside his head, using the braille line primarily as a tool for finding the right spot for his corrections or amendments.
When I read that airy kind of code, newlines as frequent as spaces, where I have to page down, and down, and more down, ... and then return to maybe six pages higher up, I feel a close relationship with my almost-blind friend: I must keep structure of the code in my head. I won't have the option to see it on the screen. Not unless I get myself a minimum of three huge, high resolution screens, stacked one above the other, in portrait orientation. And a ladder to climb up and down the code strand.
A common APL joke is that every APL programmer's dream is to write the entire problem solution in a single line. It looks as if a fair share of C programmers' ultimate dream is to write the entire problem solution in a single column.
|
|
|
|
|
Did you used to be active on the C++ Builder groups? I remember long ago I was working through code styles and one person had the following:
void someFunction() {
if (something) {
doThings();
}
}
The final hanging brace bothered me for a long time, but I adopted everything else because it had the greatest beauty and logical consistency of all the styles I'd seen. As I used it more and more I finally reached a day where the logic of the final hanging brace became perfectly clear, and I adopted it and never looked back! I agree with all the points you made - it is so much easier to grok the code when it has internal beauty, and doesn't take up tons of space!
|
|
|
|
|
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;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
