|
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.
|
|
|
|
|
not following pre existing conventions of code you were given to make a fix for
|
|
|
|
|
It really annoys me when people don't respect the coding style they encounter while changing someone else's code.
It's even worse when they run a reformatter that changes the entire file to their preferred style.
I think a bunch of the style quirks like #3 came from a time where the number of lines in the file made navigation arduous. I'm looking at you ed.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
MikeTheFid wrote: I think a bunch of the style quirks like #3 came from a time where the number of lines in the file made navigation arduous. I'm looking at you ed.
Not sure if it's true or just an internet legend, but I've read that the opening brace on the previous line style first gained popularity when the layout person at the publisher for what became a very influential book made the change to reduce the page count.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
MikeTheFid wrote: It's even worse when they run a reformatter that changes the entire file to their preferred style.
Yes that is a very bad thing. Makes reviewing code much harder.
|
|
|
|
|
First example would have different meanings in most languages because they aren't white space significant. The rest are just preferences and I set my IDE to allow me to quickly reformat the code to my preference.
|
|
|
|
|
return func_0(func_1(func_2(func_3()))); i may have lost a job because during interview the coder showing me his code showed me code like this and i told him i thought it was terrible . probably a good thing i didn't get it . there was a lit cigarette dangling from his mouth and i hate cigarettes .
|
|
|
|
|
Kevin Marois wrote: What bugs you when you see someone else's code?
What bugs me is when someone insists their coding style is 'better' and thus makes it a formal coding standard for the company.
Having spent more than than a decade neck deep in formal process standards including studying actual formal research I know that coding style guides have zero measurable impact on any objective quality metric.
The most common refrain is that it is more 'readable'. I spent quite a bit of time trying to find any research at all that actually objectively measured that. I found one single study which was based on marketing material (not code) which only showed that more than 4 type faces was not a good idea.
|
|
|
|
|
I also used to think like this, but my current job has taught me why one should have and follow a corporate style guide: versioning. If everyone uses linting to format code to their style after changing a single line on a file, version systems will register thousands of changes on a file and hide what has really been altered on the code. I never question this anymore but follow my own standards for my personal projects.
- Leonardo
|
|
|
|
|
Leonardo Pessoa wrote: If everyone uses linting to format code to their style after changing a single line on a file
Correct. And I agree that is a problem for exactly the same reason (even posted that in this thread on another message.)
But a formal style guide doesn't really have anything to do with that practice.
|
|
|
|
|
Took me a while to figure out the first one was legal C.
It's also a pet peeve of mine. But after years of seeing and understanding the most elegant hacks and algorithms (and then a lot of the asm keyword)...you resign yourself to knowing K&R syntax is optional.
Readability being a pipe dream (since in my field, thinking like the computer is the highest form of enlightenment for an engineer)
|
|
|
|
|
I shall disagree on #3 because I prefer exactly the opposite. Apart from that, pretty much only poorly written code annoys me. I clearly remember the time I've been maintaining someone else's code just to read the following statement (methods and variable names have been changed to preserve the code, although kept the language):
class TReport1 : TReport
private
shouldPrint: boolean;
end;
procedure TReport1.Label1Print(var print: boolean);
begin
if shouldPrint = true then
print = true;
else
print = false;
end;
I swear that it was exactly like this. All over the code, repeated a thousand time for each element on the report (yes, the person didn't even reuse the same method). And there was nothing else, nothing to control or change the value of shouldPrint. I was tempted to rewrite it all but time and the rule of not messing with what is working prevented me. I still have nightmares with this code...
- Leonardo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
