|
Rick York wrote: Especially when that hard-coded value needs to be changed.
All code will need to change. That is just a fact of life.
But coding for all possible futures just leads to code that is hard to understand and maintain in all futures.
|
|
|
|
|
That was remarkably non sequitur. 
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: Use of literal values annoys me a lot. Especially when that hard-coded value needs to be changed.
Only if the literal value is a parameter that can potentially have different values. Too often I've seen things that are as silly as
static const int two=2;
static const string emptyString="";
or maybe
static const string fooBar="fooBar";
So there are limits to when replacing hard coded values by identifiers is a good idea.
|
|
|
|
|
Kevin Marois wrote: I just can stand it when someone doesn't use braces in IF statements:
For me, that's acceptable... as long as the rest of the code is formatted well. Especially for stuff that's terse in nature like if (!blah) return; at the start of a routine. But it would have to be something short and simple.
Kevin Marois wrote: What bugs you when you see someone else's code?
If we harken back to the first point... when folks don't use spacing properly. Code should read like text. And in English we have paragraphs. When I see large code files with no blank lines... I mean... what?
function checkout(goodsPrice, shipmentPrice, taxes) {
const total = goodsPrice + shipmentPrice + taxes;
const para = document.createElement("p");
para.textContent = `Total price is ${total}`;
document.body.appendChild(para);
}
function checkout(goodsPrice, shipmentPrice, taxes) {
const total = goodsPrice + shipmentPrice + taxes;
const para = document.createElement("p");
para.textContent = `Total price is ${total}`;
document.body.appendChild(para);
}
Jeremy Falcon
|
|
|
|
|
At least in C/C++ putting the opening bracket on the same line as a function definition
int f(int x) {
}But that's OK in classes - particularly if its a one-liner
class C {
int x;
int f(int n) { return x*n; }
{;
Keep Calm and Carry On
|
|
|
|
|
It's not exactly code, but comment boxes in the form of complete rectangles. The pinheads who originally drew them presumably believed that other people adding comments in the box would bother to keep its right-hand border nicely aligned. Not to mention that many of those comments provided a revision history for even the most trivial changes when, even in 1981, we had a source code management system that provided a full history, so that you could see who made each change, why, and get a diff between whichever versions you wanted.
|
|
|
|
|
But where is that VCS today? The source probably is still here. It feels so good to look at the header in a file originally committed into Jedi VCS years later checked in into an SVN repo with no option to keep the history to see where our journey began.
|
|
|
|
|
It was a proprietary VCS that is still in use. Some former colleagues are still using it, and some of my commits would probably still be there over 20 years later! Once released software had been proven for long enough, most of the history in that release would be deleted to free up storage space, which was at more of a premium back then. Code ownership was part of the culture, so one thing it supported was ownership of each code file by a user group, so that only members of the group could "open" a file for a commit. A file in the OPEN state also served as a warning so that anyone working on a private copy could consult with the developer changing the code to avoid merge conflicts.
modified 31-May-23 6:58am.
|
|
|
|
|
Greg Utas wrote: The pinheads who originally drew them presumably
Well to be fair I wasn't a pinhead when I did that very long ago. Just inexperienced.
Greg Utas wrote: most trivial changes when, even in 1981, we had a source code management system that provided a full history
There are two comments for that one.
One it is just so cool the first time one figures out source control macros. Who can't resist using the one that inserts the change history?
Two been a while but it was after the year 2000 when a company I interviewed for, when I asked what source control system they were using, the interviewer explained that they had been considering putting one of those in place so my experience would fit well with that.
|
|
|
|
|
I would take offense to #1 and #2, but not #3. I use the K&R style of bracing.
/ravi
|
|
|
|
|
|
I have enough trouble with my own code... 
|
|
|
|
|
#1 and #3, except #3 is the style for JavaScript/TypeScript, so I have to live with it. 
#2 - I don't do XAML but yes, I would agree.
|
|
|
|
|
2.
VS | Options | XAML | Formatting | Spacing |
(0) Position each attribute on a separate line ...
[x] Position first attribute on same line as start tag.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I program in VB6..... so none of this matters!!! 
|
|
|
|
|
I just follow the house coding standards whatever they are, which just ensures the coding style is consistent across the department.
I am not a fan of one line if statements unless the statement is on the same line as the condition.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
#1 I have no issues at all with the absence of braces but code must be indented correctly at ALL times, no excuses or exceptions
#2 I don't really care, maybe I'd enable auto wrap or reformat the code to do it, luckily I don't see it often
#3 just for C#, for C++ I prefer on the same line and even for C# it's just because there is a preferred style and it would be dumb to go against the current, if it wasn't for that, braces would be on the same line
|
|
|
|
|
inconsistant naming. 
|
|
|
|
|
People who go against the editor's defaults 
I'm currently working on a project where the developer uses two spaces instead of the default four.
So now, whenever I change a file and I save it, Visual Studio reformats the entire file to have four spaces.
We're now working with editorconfig files...
Same for curly braces on the same line, seen it before and Visual Studio just keeps trying to correct me.
At one time I've even seen a project where curly braces and semi-colons were always aligned to the end of a line, like on column 800 or something 
How the ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) does someone think "let's mess up the VS settings before starting to write code!" and then go all out of his way to have such an unnatural coding style
|
|
|
|
|
I prefer the two-space indent over four because it saves screen space. Visual Studio has a lot of useful windows surrounding the text editor. Using two-space indents allows more text to be seen.
Some of my colleagues and I have used two as the default since the Turbo Pascal days when we only had 80 columns to work with. Seeing a file formatted with four spaces after all these years just seems wasteful.
My code uses has increased the use of shorter functions over the years so running off the screen is not as much of a problem as it was when I started.
|
|
|
|
|
Maybe they're using emacs! Not joking, by the way.
|
|
|
|
|
It is not my usual messy stuff...
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Kevin Marois wrote: What bugs you when you see someone else's code?
I find improper find grammar unbearable! 
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Quite happy about if one-liners, religious about #3. And only comment that which is not obvious.
Paul Sanders.
If I had more time, I would have written a shorter letter - Blaise Pascal.
Some of my best work is in the undo buffer.
|
|
|
|
|
I don't the understand the hate for #3. From the other comments I appear to be in the minority.
Mostly because it saves vertical space and still provides a well defined block for the conditional statement.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
