|
Will it be over easy, or they will chicken out?
I, for one, like Roman Numerals.
|
|
|
|
|
Scrambled I'm thinking! 
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
Bacon is what I'm thinking now...
Mmmmmmm Baaaaconnnnn! 
I, for one, like Roman Numerals.
|
|
|
|
|
This one made me genuinely laugh.  
|
|
|
|
|
you like that? can see the wheels turning [in a happy way].
begs the question: so how many years were you in for are missing on your CV? 
Message Signature
(Click to edit ->)
|
|
|
|
|
lopatir wrote: so how many years were you in for are missing on your CV?
Oh, I filled the gaps in nicely. No worries. Just takes a little more ink.
|
|
|
|
|
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
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...
modified 19-Nov-19 10:02am.
|
|
|
|
|
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... 
|
|
|
|
|
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?"
|
|
|
|
|
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?
|
|
|
|
|
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.
modified 19-Nov-19 9:34am.
|
|
|
|
|
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.
|
|
|
|
|
Super Lloyd wrote: But go ahead, restyle my code, I don't mind....
This is what Ctrl-K Ctrl-D is for. It allows me to restyle your code for me to read easier.
|
|
|
|
|
Yeah my boss here has a unique style settings and he restyle all files he gaze upon. That's funny!
|
|
|
|
|
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: 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???
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.
|
|
|
|
|
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
|
|
|
|
|
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! 
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! Mind blown!
modified 19-Nov-19 12:10pm.
|
|
|
|
|
Super Lloyd wrote: In fact no style enforcement might help you discover code that has been poorly maintained! Mind blown!
I'm glad we agree on that
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!
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
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
|
|
|
|
|
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 01
This 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!?
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? 
|
|
|
|
|
Sander Rossel wrote: But why not skilled and tidy?
As long as you don't make a religion of it, including conducting code reviews like the inquisition and hobby advocates who constantly add new rules to the 'style guide', plus previous decisions of the inquisition and lists of exceptions to the rules.
I prefer not to degrade the entre team to code monkeys or better secretaries. Remote controlling everyone and dictating exactly what they have to write and where they have to put it is much too stressy. Then it's easier to just write it myself.
A more tolerant approach does not descend into anarchy. Your team will automatically find a style that everyone can live with, simply because they start to feel responsible when they are not constantly discouraged by some control freak. I learned that lesson very early, at a place where most people would not expect it.
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
