|
  My autonomous fingers obviously prefer ATE to ANT.
Any my proof-reading glasses fell off, obviously.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
You were unlucky and you probably gave it away - but it was always going to be solved.
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
UNDULATE?
But I'm not sure how! It's almost an anagram of adult nun?
|
|
|
|
|
Nope
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
Maybe UNDULANT then - which is an anagram of ADULT NUN
|
|
|
|
|
 YAUT
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
A Fairly Generic Comparison to Make - The Daily WTF
Quote: my name is missing (unregistered)
Encapsulating stupid ideas in a single place is simply turning spaghetti code into ravioli.
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
|
|
|
|
|
apart from method, field and property casing, which I will be the first to admit is purely cosmetic, yet still rubs me the wrong way when a property start with a lower case and a field start with an uppercase....
I still find, 18 years later (after starting working with C# professionally) that all those discussion about where to put bracket, whether or not to use LinQ or not, or whatever, to return at the end of the method or not, so called micro consistency, are all a monumental waste of time. Never ever ever ever had this any impact on how difficult or easy was a codebase to understand... 
Nothing particular to moan on... except the codebase I am looking at is quite hard to understand... and no amount of "styling" that could fix it, and for some reason I got memory of endless pointless painful discussion about it... I think I have code styling PTSD 
At best, at risk of being pedantic meself, I would say "proper MVVM" could improve it... i.e. data only model and binding only UI. But I find purist so annoying, and I can see that code has history....
That said "proper MVVM", or an approximation of it, is often an improvement toward reducing code complexity.. 
(though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
|
|
|
|
|
Personally, I use lowercase for local and private members and Pascal case for anything externally visible -- including parameter names. Just to piss people off.
|
|
|
|
|
I handle discussion of the best way to format code using Ctrl-K, D, which in VS reformats the code to your liking.
|
|
|
|
|
Winner! 
|
|
|
|
|
And then you have two developers with different settings at war with each other - and I have to code review the code going back and forth... and try to track actual changes... no thanks.
|
|
|
|
|
0) If I'm editing an existing file, I follow the formatting already in that file. If I'm creating a new file - in the absence of established corporate coding standards - I use my own style.
1) I never reformat a file to my style because source control would mark every line as being changed when I checked it back in.
2) I always put accessors on private elements.
3) I always use this., or in the case of static classes, I use ClassName. to denote local class members.
4) I use lowercase chars to start field/method variable names, and camel-case them if necessary.
5) I start class, property, and method names with uppercase chars, and camel-case them if necessary.
6) I put curly braces on their own lines.
7) I'm a fanatic for code alignment.
8) I use LINQ when it makes sense to do so, mostly because it cleans up the code so well without loosing fidelity.
9) I "keep tabs". After I demonstrated why to the rest of the team, they agree it's the best way to go. We have one guy that was doing 5 spaces instead of four when he hit the tab key. This helped him immensely because VS uses five spaces for him, and four for the rest of us.
10) I comment pretty much everything, at least the "why" of it.
Fortunately, I'm currently in a position where I can dictate styling for my team. Even more fortunate, they already used pretty much the same styling techniques.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I am in a position where I could dictate, but I certainly do not want to if I can avoid it - I try to nudge people in the right direction when possible.
For the rest: yes, you use pretty average code standards like we all do. With some variations like most have. I had to change a thing or two to match the tools, but then - if it was important I could have changed the tool settings - but it was not important.
|
|
|
|
|
Super Lloyd wrote: apart from method, field and property casing, which I will be the first to admit is purely cosmetic
Not completely, it helps you make assumptions about your code so you don't have to think about every little detail.
Not constantly having to check whether something is a method or variable or whatever, because it's consistently cased, lowers the cognitive load while reading code.
Most code is already hard enough to read without you having to worry whether something is a field, variable or property.
For example, you could make assumptions about the following code:
public ReturnTheValue(int a) => a + b + C; a is a variable passed to the method, b is probably a private field and C is probably a public property.
You'd be surprised if b was the property and C was the field, it'd be a WTF, and as we all know there's only one good metric for code quality... WTFs per minute.
So just a little more than cosmetics, I'd argue
|
|
|
|
|
Ok, ok, it's a bit more than just cosmetic. Lucky me, that's the only code style I find worth enforcing!
|
|
|
|
|
But... MVVM means you need a UI framework :P
Funny how we don't complain about that with desktop apps
|
|
|
|
|
I rather think of WPF as a UI library. Not a Framework.
While Framework force you to work their way to do (arguably new) stuff, UI library empower you to do stuff however you like!
|
|
|
|
|
Frameworks for desktop applications are just as bad.
|
|
|
|
|
I find that consistent code styling (whatever style you use) also helps with code comparisons / merges.
|
|
|
|
|
Consistency helps a bit when reading code, but it comes with two drawbacks in my view: Endless discussion and code review focusing on formatting while no-one notice the structure of the code is complete crap.
We did find a solution to this in our team. A bit too heavy impact to apply in old projects but for anything new we do it from the start: Analyzers.
We use Stylecop and NETAnalyzers (or whatever fxcop was renamed to.... or do we still have FXCop and it was Stylecop renamed? Who knows? Who cares?) and a few others.
We suppress some things (no file headers, no requirement to document public methods in anything but public APIs). There is no strict rule for what we suppress, but any suppression also goes through code review, and typically "this adds a lot of work and no benefit" will be accepted while "it looks better this way" is unlikely to get through - at least as a global suppression.
In the start there is the usual complains about prefixing with "this." and placing using statements inside the namespace declaration. Luckily there is a solution: Simply say "sure, we can change it if you don't like it, just try doing it 3-6 months then we will discuss what we want to change. Most will live with this "mandate" form a senior. After all, in 3-6 months they will have the discussion and they can get this stupidity changed.... Then after 3-6 months, they realized it just doesn't matter and don't want to change anything.
Set the release build to treat warnings like errors - and force a build on merge to "develop" or whatever branch you use and formatting is "just taken care of" by tools as it should be.
|
|
|
|
|
lmoelleb wrote: Endless discussion and code review focusing on formatting while no-one notice the structure of the code is complete crap.
We don't talk about formatting in our code reviews, unless the format of the target code does not follow the formatting in the rest of the file.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
So if I understand you correct: You check (and if needed talk about) formatting in the code reviews.
Of course, once developers get used to following whatever you have it is not often it has to be brought up - we work that way in the old code as well.
It's just so much easier in the new code. It's trivial work, exactly the thing computers where invented to do.
|
|
|
|
|
No we don't make it part of the code review itself. If the formatting is way off, we mention it at the end of the review, but it's not a "topic of discussion".
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Fair enough, we just use different wordings. Something that is checked and potentially mentioned (even briefly) I see as part of the review, but you do not. In the end I think we in practice do the same thing.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
