Code analysis
-
I just turned my message analysis on... And in the see of 400 warning for library I am look at right now. I think I spotted 2 useful comment.... They really need to improved this feature... :/ (i.e. I can't spot the 0.5% useful comments most time) like style | possible error | pattern recommendation EditorConf seems all about style as far as I can see... :( [EditorConfig settings - Visual Studio | Microsoft Docs](https://docs.microsoft.com/en-au/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019#add-an-editorconfig-file-to-a-project) I certainly don't care about style consistency in my home project. Better yet, I like to change style over time! Ha! Take that stupid style enforcer! [EDIT] Found a solution.. instead of simply ignoring code analysis.. I create a ruleset, disable everything and the cherry pick a few promising looking rules... what I really would like to know is, how easy to make new one? I'd like to create a warning when people to await Task object (which throw no warning in non async method by default)... Would caught some bug in our project... :/ [EDIT2] I checked those 3 rules - Avoid excessive inheritance - Avoid excessive complexity - Avoid unmaintainable code Now I am curious to see where it will apply ^^ [EDIT3] The fracking ruleset doesn't work! (in Visual Studio 2019 Community) I told it to ignore rule 2208, restarted Visual Studio, it still warns me about it... That's it, stuff it, I can't be bothered to use it anymore... there might be 0.5% useful warning, but they are just too hard to use...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I just turned my message analysis on... And in the see of 400 warning for library I am look at right now. I think I spotted 2 useful comment.... They really need to improved this feature... :/ (i.e. I can't spot the 0.5% useful comments most time) like style | possible error | pattern recommendation EditorConf seems all about style as far as I can see... :( [EditorConfig settings - Visual Studio | Microsoft Docs](https://docs.microsoft.com/en-au/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019#add-an-editorconfig-file-to-a-project) I certainly don't care about style consistency in my home project. Better yet, I like to change style over time! Ha! Take that stupid style enforcer! [EDIT] Found a solution.. instead of simply ignoring code analysis.. I create a ruleset, disable everything and the cherry pick a few promising looking rules... what I really would like to know is, how easy to make new one? I'd like to create a warning when people to await Task object (which throw no warning in non async method by default)... Would caught some bug in our project... :/ [EDIT2] I checked those 3 rules - Avoid excessive inheritance - Avoid excessive complexity - Avoid unmaintainable code Now I am curious to see where it will apply ^^ [EDIT3] The fracking ruleset doesn't work! (in Visual Studio 2019 Community) I told it to ignore rule 2208, restarted Visual Studio, it still warns me about it... That's it, stuff it, I can't be bothered to use it anymore... there might be 0.5% useful warning, but they are just too hard to use...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I never quite got this obscession with style anyway. The computer does not care about it at all, as long as the parser can make sense of what it has been fed. And I have also seen enough pigs with stylish lipstick, yet still most developers do their best to ignore the real problems and just make a big fuss to prevent the lipstick from getting smeared. Sometimes I think this is some sort of modern supersticion. They invent arcane rituals with arcane rules which don't really help very much, but are fanatically persued anyway.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
I never quite got this obscession with style anyway. The computer does not care about it at all, as long as the parser can make sense of what it has been fed. And I have also seen enough pigs with stylish lipstick, yet still most developers do their best to ignore the real problems and just make a big fuss to prevent the lipstick from getting smeared. Sometimes I think this is some sort of modern supersticion. They invent arcane rituals with arcane rules which don't really help very much, but are fanatically persued anyway.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
I never understood it either... I suspect (maybe smug intolerance at play) that it is due to the influence of a larger than expected number of average or below programmers... :sigh:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I never quite got this obscession with style anyway. The computer does not care about it at all, as long as the parser can make sense of what it has been fed. And I have also seen enough pigs with stylish lipstick, yet still most developers do their best to ignore the real problems and just make a big fuss to prevent the lipstick from getting smeared. Sometimes I think this is some sort of modern supersticion. They invent arcane rituals with arcane rules which don't really help very much, but are fanatically persued anyway.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
Style is important because you're writing code for developers to read, not for computers. When style is consistent, code will look familiar at first sight and it will save any other developer, or you next year, the trouble of first deciphering the syntax before actually trying to understand what it does. When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right. It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Style is important because you're writing code for developers to read, not for computers. When style is consistent, code will look familiar at first sight and it will save any other developer, or you next year, the trouble of first deciphering the syntax before actually trying to understand what it does. When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right. It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
the problem when people go into fight over style, not only it is an endless pointless waste of time, but also people have extremely simplistic style guideline. like the eternal recurring waste of time "always use brace after an if" sorry, but I have like 5 bracing style depending on context and length of enclosing statement.... and your over simplification is as irking to me as I am to you.... But go ahead, restyle my code, I don't mind.... Further.. I found many case where this obsession over style and patterns over functionality was getting in the way of fixing bug and was in fat creating new ones... :( In a way, I am NOT an Apple person.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Style is important because you're writing code for developers to read, not for computers. When style is consistent, code will look familiar at first sight and it will save any other developer, or you next year, the trouble of first deciphering the syntax before actually trying to understand what it does. When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right. It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
Style is important because you're writing code for developers to read, not for computers.
Style is not important because you're writing code for compiler to read, not for developers. Seriously, did you ever proofread newspaper articles? When something has been written too 'nicely', that may lead to readers believing that they already know what the article is about without actually reading it. It may actually help when a little more mental effort is required to understand a text.
Quote:
When style is consistent, code will look familiar at first sight
And that's exactly not what I would want.
Quote:
When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right.
How do you think I feel about someone who screams bloody murder over something that's obviously not important to me. :-)
Sander Rossel wrote:
It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Please, tell me all about it. My boss must have lived in China in a previous life. He reformats every XAML so that every attribute in a tag gets its own line and indents everything with just two spaces. The whole thing becomes miles long and with all that scrolling I constantly lose sight of where something begins or ends. The other way around, when I reformat it so that I can see the forrest for all the trees again, he gets similar problems. Here decade old habits collide and there just is no middle ground. Poor Sander, how much Cool Aid did they give you to drink? :-?
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
I just turned my message analysis on... And in the see of 400 warning for library I am look at right now. I think I spotted 2 useful comment.... They really need to improved this feature... :/ (i.e. I can't spot the 0.5% useful comments most time) like style | possible error | pattern recommendation EditorConf seems all about style as far as I can see... :( [EditorConfig settings - Visual Studio | Microsoft Docs](https://docs.microsoft.com/en-au/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019#add-an-editorconfig-file-to-a-project) I certainly don't care about style consistency in my home project. Better yet, I like to change style over time! Ha! Take that stupid style enforcer! [EDIT] Found a solution.. instead of simply ignoring code analysis.. I create a ruleset, disable everything and the cherry pick a few promising looking rules... what I really would like to know is, how easy to make new one? I'd like to create a warning when people to await Task object (which throw no warning in non async method by default)... Would caught some bug in our project... :/ [EDIT2] I checked those 3 rules - Avoid excessive inheritance - Avoid excessive complexity - Avoid unmaintainable code Now I am curious to see where it will apply ^^ [EDIT3] The fracking ruleset doesn't work! (in Visual Studio 2019 Community) I told it to ignore rule 2208, restarted Visual Studio, it still warns me about it... That's it, stuff it, I can't be bothered to use it anymore... there might be 0.5% useful warning, but they are just too hard to use...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
Avoid excessive inheritance
Quote:
A type is more than four levels deep in its inheritance hierarchy.
Wow. I have seen samples to teach about inheritance which already are 'excessive' by this definition.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Sander Rossel wrote:
Style is important because you're writing code for developers to read, not for computers.
Style is not important because you're writing code for compiler to read, not for developers. Seriously, did you ever proofread newspaper articles? When something has been written too 'nicely', that may lead to readers believing that they already know what the article is about without actually reading it. It may actually help when a little more mental effort is required to understand a text.
Quote:
When style is consistent, code will look familiar at first sight
And that's exactly not what I would want.
Quote:
When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right.
How do you think I feel about someone who screams bloody murder over something that's obviously not important to me. :-)
Sander Rossel wrote:
It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Please, tell me all about it. My boss must have lived in China in a previous life. He reformats every XAML so that every attribute in a tag gets its own line and indents everything with just two spaces. The whole thing becomes miles long and with all that scrolling I constantly lose sight of where something begins or ends. The other way around, when I reformat it so that I can see the forrest for all the trees again, he gets similar problems. Here decade old habits collide and there just is no middle ground. Poor Sander, how much Cool Aid did they give you to drink? :-?
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Style is important because you're writing code for developers to read, not for computers. When style is consistent, code will look familiar at first sight and it will save any other developer, or you next year, the trouble of first deciphering the syntax before actually trying to understand what it does. When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right. It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
CodeWraith wrote:
Quote:
When style is consistent, code will look familiar at first sight
And that's exactly not what I would want.
ummm, copy much from QA is it? or just plagiarism in general??? :-D
Message Signature (Click to edit ->)
I think my ratio of own code to stolen code is very acceptable and some of my stuff would be an eternal riddle to someone who has to resort to plagiarism. :-)
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
I just turned my message analysis on... And in the see of 400 warning for library I am look at right now. I think I spotted 2 useful comment.... They really need to improved this feature... :/ (i.e. I can't spot the 0.5% useful comments most time) like style | possible error | pattern recommendation EditorConf seems all about style as far as I can see... :( [EditorConfig settings - Visual Studio | Microsoft Docs](https://docs.microsoft.com/en-au/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019#add-an-editorconfig-file-to-a-project) I certainly don't care about style consistency in my home project. Better yet, I like to change style over time! Ha! Take that stupid style enforcer! [EDIT] Found a solution.. instead of simply ignoring code analysis.. I create a ruleset, disable everything and the cherry pick a few promising looking rules... what I really would like to know is, how easy to make new one? I'd like to create a warning when people to await Task object (which throw no warning in non async method by default)... Would caught some bug in our project... :/ [EDIT2] I checked those 3 rules - Avoid excessive inheritance - Avoid excessive complexity - Avoid unmaintainable code Now I am curious to see where it will apply ^^ [EDIT3] The fracking ruleset doesn't work! (in Visual Studio 2019 Community) I told it to ignore rule 2208, restarted Visual Studio, it still warns me about it... That's it, stuff it, I can't be bothered to use it anymore... there might be 0.5% useful warning, but they are just too hard to use...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Turn the rule on to not waste an hour of your life with code analysis. You either write good code or you don't. Empower yourself, not the machine. :)
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
I never understood it either... I suspect (maybe smug intolerance at play) that it is due to the influence of a larger than expected number of average or below programmers... :sigh:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Definitely. To me, it also explains the explosion of languages for this and that which are supposed to "make it easier." Plus, there is this movement that says, "everyone can code." Unfortunately, we can not add the adverb "well" to the end of that sentence. It would be more like, "sort of."
"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?"
-
I just turned my message analysis on... And in the see of 400 warning for library I am look at right now. I think I spotted 2 useful comment.... They really need to improved this feature... :/ (i.e. I can't spot the 0.5% useful comments most time) like style | possible error | pattern recommendation EditorConf seems all about style as far as I can see... :( [EditorConfig settings - Visual Studio | Microsoft Docs](https://docs.microsoft.com/en-au/visualstudio/ide/create-portable-custom-editor-options?view=vs-2019#add-an-editorconfig-file-to-a-project) I certainly don't care about style consistency in my home project. Better yet, I like to change style over time! Ha! Take that stupid style enforcer! [EDIT] Found a solution.. instead of simply ignoring code analysis.. I create a ruleset, disable everything and the cherry pick a few promising looking rules... what I really would like to know is, how easy to make new one? I'd like to create a warning when people to await Task object (which throw no warning in non async method by default)... Would caught some bug in our project... :/ [EDIT2] I checked those 3 rules - Avoid excessive inheritance - Avoid excessive complexity - Avoid unmaintainable code Now I am curious to see where it will apply ^^ [EDIT3] The fracking ruleset doesn't work! (in Visual Studio 2019 Community) I told it to ignore rule 2208, restarted Visual Studio, it still warns me about it... That's it, stuff it, I can't be bothered to use it anymore... there might be 0.5% useful warning, but they are just too hard to use...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
I told it to ignore rule 2208
Do you like to run around in a bathrobe all day ("Execute order 66!") or do you prefer something more colorful ("Implement General Order 24!")? :-) Every nerd who knows what I am talking about may drop a comment :-)
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Sander Rossel wrote:
Style is important because you're writing code for developers to read, not for computers.
Style is not important because you're writing code for compiler to read, not for developers. Seriously, did you ever proofread newspaper articles? When something has been written too 'nicely', that may lead to readers believing that they already know what the article is about without actually reading it. It may actually help when a little more mental effort is required to understand a text.
Quote:
When style is consistent, code will look familiar at first sight
And that's exactly not what I would want.
Quote:
When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right.
How do you think I feel about someone who screams bloody murder over something that's obviously not important to me. :-)
Sander Rossel wrote:
It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Please, tell me all about it. My boss must have lived in China in a previous life. He reformats every XAML so that every attribute in a tag gets its own line and indents everything with just two spaces. The whole thing becomes miles long and with all that scrolling I constantly lose sight of where something begins or ends. The other way around, when I reformat it so that I can see the forrest for all the trees again, he gets similar problems. Here decade old habits collide and there just is no middle ground. Poor Sander, how much Cool Aid did they give you to drink? :-?
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
CodeWraith wrote:
Style is not important because you're writing code for compiler to read, not for developers.
I think probably 80% of a developer's job is reading code. The compiler can read long sentences, short sentences, clear variable names and garbage variable names. The compiler could read an entire multi million line C# application condensed in a single line. Humans cannot. Luckily, we have plenty of people who make our job really very hard so we won't get bored.
CodeWraith wrote:
How do you think I feel about someone who screams bloody murder over something that's obviously not important to me. :)
A programmer who doesn't care about his code is like an author who doesn't care about his book. To be clear, I don't really mind an extra white space, or an underscore. But I've had code like this:
public class someClass
{
Int32 _someVariable;
int AnotherVariable;
Point Some_Point;
private string privateVariable;
}class AnotherClass
{
}I wish I was joking or overreacting, but that's what I got. We have inconsistency in PascalCase, camelCase, underscores, access modifiers and even the class names for built-in types like int. And when it's everywhere, in 1000 line classes, it becomes difficult to even just read let alone understand what it does.
CodeWraith wrote:
He reformats every XAML so that every attribute in a tag gets its own line and indents everything with just two spaces.
I do that with my C# code too. Or rather, Visual Studio does it for me when I ctrl + k, d. And with this cool plugin I have it happens automatically on save, because I care about my code :)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
the problem when people go into fight over style, not only it is an endless pointless waste of time, but also people have extremely simplistic style guideline. like the eternal recurring waste of time "always use brace after an if" sorry, but I have like 5 bracing style depending on context and length of enclosing statement.... and your over simplification is as irking to me as I am to you.... But go ahead, restyle my code, I don't mind.... Further.. I found many case where this obsession over style and patterns over functionality was getting in the way of fixing bug and was in fat creating new ones... :( In a way, I am NOT an Apple person.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Pick a style, stick to it. I don't really care that one person uses a bit more white space or has a funny way of naming variables (as long as it's clear) or uses var instead of the type name. But there should be some sort of unity in a code base. The basic ctrl + k, d together with things Visual Studio warns about (for example camelCase where PascalCase is expected and vice versa) should suffice.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Sander Rossel wrote:
Style is important because you're writing code for developers to read, not for computers.
Style is not important because you're writing code for compiler to read, not for developers. Seriously, did you ever proofread newspaper articles? When something has been written too 'nicely', that may lead to readers believing that they already know what the article is about without actually reading it. It may actually help when a little more mental effort is required to understand a text.
Quote:
When style is consistent, code will look familiar at first sight
And that's exactly not what I would want.
Quote:
When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right.
How do you think I feel about someone who screams bloody murder over something that's obviously not important to me. :-)
Sander Rossel wrote:
It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?
Please, tell me all about it. My boss must have lived in China in a previous life. He reformats every XAML so that every attribute in a tag gets its own line and indents everything with just two spaces. The whole thing becomes miles long and with all that scrolling I constantly lose sight of where something begins or ends. The other way around, when I reformat it so that I can see the forrest for all the trees again, he gets similar problems. Here decade old habits collide and there just is no middle ground. Poor Sander, how much Cool Aid did they give you to drink? :-?
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
Varied skill levels of team members make style enforcement an important tool to be sure you can assign the work to almost anyone on your team without too much hassle about "style-stink". You just have to get buy-in from the team because enforcing it without their buy-in only increases resentment. That, and making in-line comments for hard-to-follow code blocks can make a world of difference for the guys who have to come in after you to maintain the code. That's my story and I'm sticking to it.
-
Turn the rule on to not waste an hour of your life with code analysis. You either write good code or you don't. Empower yourself, not the machine. :)
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsThe frustrating bit is.. I spotted a few useful tips... but there is like 400 messages for one assembly, of which maybe 5 messages are useful. But in the end I search and find these messages like once a year... I am never gonna scan them all successfully on every compile or even once every day... And then.. it's working less and less well to turn them on and off.. (between each edition of visual studio) but that might be because I have the Community edition at home. Going to check pro edition at work tomorrow! Would be good to know if professional works better.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Super Lloyd wrote:
I told it to ignore rule 2208
Do you like to run around in a bathrobe all day ("Execute order 66!") or do you prefer something more colorful ("Implement General Order 24!")? :-) Every nerd who knows what I am talking about may drop a comment :-)
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
I am gonna order 66 the godamn code analysis extensions! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
CodeWraith wrote:
Style is not important because you're writing code for compiler to read, not for developers.
I think probably 80% of a developer's job is reading code. The compiler can read long sentences, short sentences, clear variable names and garbage variable names. The compiler could read an entire multi million line C# application condensed in a single line. Humans cannot. Luckily, we have plenty of people who make our job really very hard so we won't get bored.
CodeWraith wrote:
How do you think I feel about someone who screams bloody murder over something that's obviously not important to me. :)
A programmer who doesn't care about his code is like an author who doesn't care about his book. To be clear, I don't really mind an extra white space, or an underscore. But I've had code like this:
public class someClass
{
Int32 _someVariable;
int AnotherVariable;
Point Some_Point;
private string privateVariable;
}class AnotherClass
{
}I wish I was joking or overreacting, but that's what I got. We have inconsistency in PascalCase, camelCase, underscores, access modifiers and even the class names for built-in types like int. And when it's everywhere, in 1000 line classes, it becomes difficult to even just read let alone understand what it does.
CodeWraith wrote:
He reformats every XAML so that every attribute in a tag gets its own line and indents everything with just two spaces.
I do that with my C# code too. Or rather, Visual Studio does it for me when I ctrl + k, d. And with this cool plugin I have it happens automatically on save, because I care about my code :)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
public class someClass
{
Int32 _someVariable;
int AnotherVariable;
Point Some_Point;
private string privateVariable;
}class AnotherClass
{
}I wish I was joking or overreacting, but that's what I got. We have inconsistency in PascalCase, camelCase, underscores, access modifiers and even the class names for built-in types like int.
For a moment I was wondering what was the problem here.. and then you explain. it is indeed funny looking... I have to say it doesn't bother me much though... unless it's camel casing on public members.. which jump to my eyes as ugly... I just tend to refactor them without warning.... even the useless private modifier on implicitly private field (or lack of it on the others, if it's your thing), I can just ignore gleefully! ;P In fact it's a sign of the following phenomena: - developer 1 write code - developer 2 fix code without understanding what's going, by adding a new layer on top and leave many things untouched... - repeat - building block complexity and frailty grow over revision, instead of simplifying and consolidating if there was an argument to be made, it's not so much about style, but that developer don't take ownership of the code they change and don't take time to understand it well either. And I am afraid that enforcing style will only enforce the illusion that the code is well maintained, as opposed to it be really well maintained in practice.... In fact no style enforcement might help you discover code that has been poorly maintained! :O Mind blown! :O
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
CodeWraith wrote:
Style is not important because you're writing code for compiler to read, not for developers.
I think probably 80% of a developer's job is reading code. The compiler can read long sentences, short sentences, clear variable names and garbage variable names. The compiler could read an entire multi million line C# application condensed in a single line. Humans cannot. Luckily, we have plenty of people who make our job really very hard so we won't get bored.
CodeWraith wrote:
How do you think I feel about someone who screams bloody murder over something that's obviously not important to me. :)
A programmer who doesn't care about his code is like an author who doesn't care about his book. To be clear, I don't really mind an extra white space, or an underscore. But I've had code like this:
public class someClass
{
Int32 _someVariable;
int AnotherVariable;
Point Some_Point;
private string privateVariable;
}class AnotherClass
{
}I wish I was joking or overreacting, but that's what I got. We have inconsistency in PascalCase, camelCase, underscores, access modifiers and even the class names for built-in types like int. And when it's everywhere, in 1000 line classes, it becomes difficult to even just read let alone understand what it does.
CodeWraith wrote:
He reformats every XAML so that every attribute in a tag gets its own line and indents everything with just two spaces.
I do that with my C# code too. Or rather, Visual Studio does it for me when I ctrl + k, d. And with this cool plugin I have it happens automatically on save, because I care about my code :)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Readability is overrated. You have a neat little pattern matcher between your ears that can reconstruct information that has been lost:
Quote:
H***o S****r, w*y d**'t y*u c**e o**r t****t f*r a b****r?
I hope I sucessfully fooled you into coming over and expecting a beer. Too bad that you did not see that there is one * too many for that word to mean beer. Just enjoy the beaver I am going to put on the grill for you. :-) There we are exacly at the problem. We are not writing poetry here and I can name a few things you should better care about before wasting a single thought on formatting or style. Deliberate obfuscation obviously is not very helpful, but you must see that your one and only style may be just as problematic or misleading for the next guy. That may even be a cultural thing. I would expect someone from Asia to be more likely to prefer to read in columns and not in rows. Do you really expect others to care for your 'poetry', even if it goes against their own one and only style? If you feel the urge to write something, then write and maintain some comments where they really are needed, or better yet, a C^4 documentation. What's C^4? Concise, current, complete and clear. That will be very much more helpful than any subjective one and only style. Do you want an example in minimalsim?
0000 7A
0001 3F 00
0003 7B
0004 30 01This is a real little program, a sort of 'Hello World' that is entered to test a little computer after soldering it together. There is not very much room for styles or creativity. Just memory addresses, opcodes and data. And it is absolutely readable for me. It even in 1978 when I did not yet know the instruction set, but the 'short course in programming' and the comments in the code listing helped a lot. Now, how much do you think I care about when someone writes something upper-, lower, camel- or even briefcase?
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
