C# code styling
-
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 :sigh: 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.. :D (though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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 :sigh: 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.. :D (though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Personally, I use lowercase for local and private members and Pascal case for anything externally visible -- including parameter names. Just to piss people off.
-
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 :sigh: 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.. :D (though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I handle discussion of the best way to format code using Ctrl-K, D, which in VS reformats the code to your liking.
Winner! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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 :sigh: 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.. :D (though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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 :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :sigh: 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.. :D (though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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 :sigh: 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.. :D (though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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! :D
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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 :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Ok, ok, it's a bit more than just cosmetic. Lucky me, that's the only code style I find worth enforcing! :D
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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 :sigh: 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.. :D (though I only argue for an approximation of it, I am here to help my colleague and myself, not annoy everyone for little gain..)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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.
-
I handle discussion of the best way to format code using Ctrl-K, D, which in VS reformats the code to your liking.
-
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. :)
- 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
privateelements. 3) I always usethis., or in the case of static classes, I useClassName.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 - 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
-
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 -
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, 2013So 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.
-
- 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
privateelements. 3) I always usethis., or in the case of static classes, I useClassName.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, 2013I 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.
- 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
-
But... MVVM means you need a UI framework :P Funny how we don't complain about that with desktop apps :)
-
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 -
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
