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!
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.
-
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
I agree that a certain amount of style is very useful. But I've worked too long with someone in, where style came before technical knowledge. And for such a case I prefer "No Style" :-\
It does not solve my Problem, but it answers my question
-
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!
Not General Order 24, just to be sure?
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.
-
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.
CodeWraith wrote:
I hope I sucessfully fooled you into coming over and expecting a beer.
I'm at your door, why won't you open!? :laugh:
CodeWraith wrote:
you must see that your one and only style may be just as problematic or misleading for the next guy
Never in the current team because they all know and recognize the style. And I hope the next guy (or girl) needs a few minutes to get used to it and then says, "alright this code seems tidy which makes it easier for me to read it and understand it".
CodeWraith wrote:
when someone writes something upper-, lower, camel- or even briefcase?
When I see a variable in PascalCase I assume it's either a constant, a method or a property. Likewise, when something is camelCased I assume it's a private variable, scoped to the current method or class. When I see an underscore prefix I assume something's a field (and that the programmer is a little older). I'm fine with a different styles, it's not my way or the highway, but this is something a lot of (.NET) programmers can relate to and sticking to that style will make things easier to read for many programmers after me. Of course, when I'm doing JavaScript I never use PascalCase and use camelCase instead. Again, I've seen PascalCase JavaScript and I'm fine with that, as long as it's consistent (although the first sight of PascalCase in JavaScript does trigger me a bit because it's unexpected). In the end, however you write your code, I will be able to understand it and to change it, but your code style (or lack thereof) may be the difference between a "that wasn't so bad" and a "wtf was that idiot thinking!?" :) Style will never make up for lack of skills and if I had to pick between a skilled and sloppy developer or an unskilled and tidy developer, I'd go for the skilled one. But why not skilled and tidy? ;)
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!
Super Lloyd wrote:
In fact no style enforcement might help you discover code that has been poorly maintained! :O Mind blown! :O
I'm glad we agree on that :laugh:
Super Lloyd wrote:
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
I guess I'm a bit OCD to just ignore that! And for the record, I add access modifiers on everything. I once had a discussion with someone who said those were all wasted keystrokes so I asked him, "alright, so what's the default modifier on this class?" He thought it was public and he didn't believe it was internal until I showed him. Needless to say, I won the argument :laugh: That code from the example I had to work with was really crappy. The styling is bad, but ultimately, it was least of my problems. SQL Server connections and business logic directly in WinForms, sort of half-binding, but also directly reading and setting values in controls, that kind of stuff. Fixing the styling so it was at least somewhat consistent did a lot. The code is still crap, but at least I'm not worrying over camelCased variables that might be public, because I've made them private or I've PascalCased them. Style can never make up for lack of skill. But as a skilled developer, I prefer to have both :cool:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I agree that a certain amount of style is very useful. But I've worked too long with someone in, where style came before technical knowledge. And for such a case I prefer "No Style" :-\
It does not solve my Problem, but it answers my question
Style never makes up for lack of skill. But why not have skill and style ;)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
Here's my response to style freaks: Your style sucks, their style sucks, my style sucks too so now that we all agree on style next item on the agenda is?...
Message Signature (Click to edit ->)
My response to you: I don't care, pick the style you think that sucks the least and stick to it. Preferably the style most developers use in that particular language. The next item on the agenda is tabs or spaces? :laugh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
