When the reviewer doesn't understand my Javascript it's his fault
-
@djls45 Do you have an example?
-
@dfdub Because they're arbitrary, contradictory, and never address actual functional concerns?
Tell me exactly what value is delivered by capitalizing a 2-letter acronym and not capitalizing a 3-letter acronym. In standard English, all acronyms are capitalized for...wait for it...readability purposes. This helps differentiate between, for example, input/output and Jupiter's fifth moon. Yet, here we are, introducing confusion in an effort that purports to reduce it.
Don't even get me started on the train wreck that is camel casing. It breaks English casing rules. Sentences start with capital letters and nowhere are proper nouns partially capitalized except stupid camel-infested online services like eBay. In fact, casing only exists because compilers won't allow spaces in variable names and the camel casing variant happened because of C++ conventions of correctly capitalizing classes. If Intellisense is a good enough reason to do away with overt type declarations and type prefixes, it's good enough to do away with lowercased first words too.
I bet if I joined your team and prefixed every variable with "the" (theCounter, theLastName, etc), the style guide people would throw a fit even though it technically passes. If I ask why it must be changed, smart money is on "because I said so," which reveals that it's really an exercise in authority. How do I know this? Because, after being scolded for including no namespaces, including 20 namespaces sent me right back to the principal's office.
Let me ask this. If you accepted a job offer, quit your old job, and, when you finally had a workstation, learned all of the code was in Klingonese, what would you do? Would you learn Klingonese? Would you take responsibility for low velocity while you learned it? All the way up to being fired and lied about?
The fact that style guides are deliberately concealed is an implicit admission of embarrassment. The organization desperately needs an expert and thinks that all it needs to do is trap one to spin their straw into gold. Sorry but it doesn't work that way. Sometimes, what makes people exceptional is how they work. Take that away and you may as well just choose a name out of the phone book or not hire anybody at all.
nothing's more infuriating and hurts readability more than such annoying inconsistencies
Having to fix somebody's bad, but style-compliant, code over and over and over is. The goal of a programmer should be to write code once and never have to look at it again. That completely sidesteps all of this hand-wringing over "readability." Having to re-read code frequently is a sign that the specifications are shit, the documentation is shit, the code is shit, or some combination of the three. If you have a style guide in place and any of these are true, fat lot of good the style guide is doing.
Your style guide, if you absolutely have to have one, should adjust to what your best programmers are doing, not codify the shortcomings of your worst.
Every time I wonder how the hell software can be so fucking awful and broken, all I have to do is remember how many places out there are more concerned about their code printing pretty than working correctly.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
How do I know this? Because, after being scolded for including no namespaces, including 20 namespaces sent me right back to the principal's office.
"I got pulled over for speeding 100 km/h over the limit on the highway so you know what I did? I went 5 km/h the next day and still got pulled over. Unbelievable!"
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
In fact, casing only exists because compilers won't allow spaces in variable names.
Such silly languages!
fun String.`add padding`() = this + "padding" infix fun String.`print stuff`(input: String) = println(this + input) fun main(args: Array<String>) { val `variable with spaces` = "A string with ".`add padding`() `variable with spaces` `print stuff` "..." }and it prints: "A string with padding..."
I wonder why most languages opt out of allowing spaces in function names?
Edit: Added some more language abuse.
-
@hungrier Not really a good analogy.
The style guide never said I must include namespaces.
The style guide did not say when to include or remove them.
Mountains of existing code included dozens of unused namespaces.
They were crying "boo hoo too many checkins and diffs are hard."Therefore, the logical conclusion was to pull in every "standard" namespace I might conceivably use.
Yet, there I was, being beaten over the head for not following a "standard" with 10 rules that all contradicted each other.
@Carnage I probably should've qualified that with "back in 1985" but the part of me that doesn't discard old things simply for being old wouldn't let me.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
In standard English, all acronyms are capitalized for...wait for it...readability purposes. This helps differentiate between, for example, input/output and Jupiter's fifth moon. Yet, here we are, introducing confusion in an effort that purports to reduce it.
The difference is, English language has spaces between words, and identifiers in code don't (except in SQL but please don't do that). CamelCase exists for the same reason why spaces exist in natural language writing. Personally, I think capitalizing two-letter acronyms is wrong too, but since in 99% of cases it's "IO", I don't care that much.
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Let me ask this. If you accepted a job offer, quit your old job, and, when you finally had a workstation, learned all of the code was in Klingonese, what would you do? Would you learn Klingonese? Would you take responsibility for low velocity while you learned it?
Happened to me twice, so I feel qualified to answer. Yes, you learn Klingonese. It's your job. You don't like it, you're free to go at any time. Do you take responsibility for low velocity? No, you don't. Even if it was language you have extensive knowledge of already, it's still not your fault I can't get anything done on time, for the first couple months until you familiarize yourself with the project. And the managers understand this. You'll never get fired for not being immediately useful as a programmer. Just remember it won't last forever, so try to learn Klingonese eventually.
Disclaimer: the above applies in corporate world. It might or might not be different in small companies.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Sentences start with capital letters and nowhere are proper nouns partially capitalized except stupid camel-infested online services like eBay.
Bad example. eBay uses the e- prefix, which stands for "electronic" - like "email". Completely different etymology from, say, YouTube.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Do you take responsibility for low velocity? No, you don't. Even if it was language you have extensive knowledge of already, it's still not your fault I can't get anything done on time, for the first couple months until you familiarize yourself with the project. And the managers understand this. You'll never get fired for not being immediately useful as a programmer.
Well, you won't unless your boss is a sociopath. Anecdote of someone else being blamed for low velocity: https://what.thedailywtf.com/topic/26407 (NOTE: Lounge topic, needs access).
-
@JBert said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Do you take responsibility for low velocity? No, you don't. Even if it was language you have extensive knowledge of already, it's still not your fault I can't get anything done on time, for the first couple months until you familiarize yourself with the project. And the managers understand this. You'll never get fired for not being immediately useful as a programmer.
Well, you won't unless your boss is a sociopath.
At which point he's making you a favor.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Happened to me twice, so I feel qualified to answer. Yes, you learn Klingonese. It's your job. You don't like it, you're free to go at any time.
The problem is that it's a trap. Do you feel the same about EULAs where the terms are only disclosed upon opening the package and opened packages cannot be returned?
Bad example. eBay uses the e- prefix, which stands for "electronic" - like "email". Completely different etymology from, say, YouTube.
So any places you have an e-mail address, do you use eMailAddress or emailAddress? e and i as prefixes are just bizarre and don't really follow any rules.
-
@Zenith pretty much. I've never found anything particularly objectionable in EULAs. Sure, they are extremely exploitative in almost every case, but not in the ways that would matter to me personally. A weird programming language isn't a deal breaker for me either. It would be nice to know everything there is to know about the job before taking it, but hey - you probably don't want your employer to know everything about you either, do you?
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Bad example. eBay uses the e- prefix, which stands for "electronic" - like "email". Completely different etymology from, say, YouTube.
So any places you have an e-mail address, do you use eMailAddress
Not anymore - language is a fluent thing - but I'm pretty sure it was a thing in early 90s. It's still eFax, ePIT, and eLot of other things.
-
@Zenith So your only argument against an enforced, consistent style is that it doesn't replace code reviews and that your ex-colleagues were incompetent despite following the rules? Because the rest of your rant only focuses on very specific styles you dislike.
Sorry, but readability and consistency is a part of "good code" to me and nothing in your reply is a convincing argument against that.
Edit: Completely missed this part:
The goal of a programmer should be to write code once and never have to look at it again.
Basically, you're saying that everyone who ever wrote a book on software engineering is lying and code and requirements don't constantly change. Also, all the statistics that say you spend more time reading code than writing it are also lying. That's a very, very unique view.
-
@Gąska Except the focus here is the job, not anybody's extracurricular activities. When I'm grocery shopping, I don't need to know that the farmer or the foreman kicks their dog but I damned well do need to know what's in the food they're selling me. Guess I just don't have enough of a libertarian bent to gamble with my life or livelihood.
The point, though, is that the person in OP is writing spaghetti code and no pretty printing style guide is going to change that. Code needs to be judged by how it works and not how it looks. The curated side of this site is rife with examples that are camel cased and have their brackets on the "right" line. It doesn't stop any of them from costing people and organizations money. All style guides and various tools to impose them do is empower little tyrants. If you're lucky, they stop there, if you're not, this happens:
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Code needs to be judged by how it works and not how it looks.
And once more, you're ignoring the need to be able to read and change code written by others. There's a broad consensus in our profession that clean code is important, but for some reason you think you know better.
I get that you don't like tyrants. Nobody does. But that doesn't change the fact that code needs to be readable and that inconsistently formatted code is hard to read.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
So your only argument against an enforced, consistent style is that it doesn't replace code reviews and that your ex-colleagues were incompetent despite following the rules?
When style guides are substituted for code reviews, as has been my experience, I stand behind that argument as completely justified. It's too easy for organizations to set up a tool and take its performance for granted.
Because the rest of your rant only focuses on very specific styles you dislike.
It's called an example. The acronym example was to show you how the rule is arbitrary and does not aid in readability. Yet, there it is in the Microsoft .NET 1.1 style guide that's a staple of development cargo cults. Would you care to enlighten me on why the acronym rule exists or do you agree that it's arbitrary?
And to take a page from your book, is your only argument for camel casing that everybody should use it because everybody uses it?
Really, unreadable is subjective. It's lucky that I can read other peoples' code, lousy format or not, because I can...read code. Not being able to read has got to be a huge handicap. It's a little harder for me to write in warped format though. I have to consciously remember to misspell words and use 32 bits when I only need a byte and remove defensive logic and act surprised later instead of rolling my eyes. If you're happy with me working at 70% capacity, fine, but that hasn't been the case.
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Basically, you're saying that everyone who ever wrote a book on software engineering is lying and code and requirements don't constantly change. Also, all the statistics that say you spend more time reading code than writing it are also lying. That's a very, very unique view.
I'll answer this with an anecdote, I was at a conference once where a speaker said "nobody wakes up in the morning and says 'damn I love our IT team.'" The audience is supposed to laugh and accept that the business area won't like them and not feel bad about themselves. In my mind, I was thinking "no, nobody wakes up and says they love your IT team." It's not that everybody hates IT inherently. They hate unresponsive and disinterested IT that does what it wants when it wants and doesn't answer to anybody.
When you start from a faulty premise, you can draw all sorts of conclusions that aren't right.
That's what happens with these books. When you're told all software has bugs, you're supposed to think defensively to mitigate their effects, not justify sloppy practices and half-baked logic because nothing really matters. When you're told that requirements change, you're supposed to write code that's flexible, not rewrite tightly coupled routines every time it changes because nothing else can be done. If the industry wasn't shifting towards nomadic mercenaries (contractors), maybe business knowledge would creep into the development team so the business area doesn't have to tell them when to move their arms and legs and how far like a mindless puppet.
Statistics that say you spend more time reading code that writing it? On the one hand,that's a self fulfilling prophecy. If you rush through shit code, no surprise that somebody will have to go back and fix it over and over and over. If you don't document, again, no mystery that somebody has to read your code to figure out WTF is going on.
It also discounts that you read as you write, And that it's code six months ago, not six minutes ago, that takes effort to get back into. There's zero cost to reading code you're in the middle of writing....unless you're a Pascal reader and writing in crippleCase, that's marginally harder (but no so much harder that crippleCase - or Pascal - should be barred). So what good is the statistic if it doesn't differentiate any of these? Besides providing "proof" that I should write your way for your convenience (but never that you should write my way for my convenience).
@Zenith said:
The goal of a programmer should be to write code once and never have to look at it again.
The goal of every job is to do it once and move on. That's how we accumulate over the long term.
Ever heard the phrase "don't reinvent the wheel?" I have. Every time I think I can do something better. But if I dress it up with a process like agile or best practices (whatever that means), I can reinvent the wheel until the sun burns out. The most defining attribute of SCRUM to me isn't the stand-up but the do-over. Don't plan ahead or think defensively. Just slap together what works this instant and wait for somebody to file a data corruption ticket. Maybe run Style Cop because something something dark side.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska Except the focus here is the job, not anybody's extracurricular activities.
The difference being, you get paid for a job. As long as they pay you as much as was agreed to, it doesn't matter much what you waste your 40 hours a week on in particular. The exceptions are when there's a risk of bodily harm, or the job is so fucked up you worry for your long term mental health (no, unexpected Klingonian isn't enough for that), or it tips off your work-life balance too much for your pay grade.
Guess I just don't have enough of a libertarian bent to gamble with my life or livelihood.
Guess I just don't have enough hatred for learning new stuff.
Code needs to be judged by how it works and not how it looks.
Any idiot can make code work. But good code is when it can be easily extended to support more use cases in the future. Consistent style (doesn't matter what style, as long as it's consistent) helps a bit. A very small bit, but still.
The curated side of this site is rife with examples that are camel cased and have their brackets on the "right" line.
An artifact of anonymization.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
identifiers in code don't
That depends on the language. Some can.
except in SQL
Not just there. That's just one of the first places that many programmers encounter them.
but please don't do that
Agreed!
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Any idiot can make code work.
No. Some can't, and for those that can it depends largely on your definition of work.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
The difference being, you get paid for a job. As long as they pay you as much as was agreed to, it doesn't matter much what you waste your 40 hours a week on in particular. The exceptions are when there's a risk of bodily harm, or the job is so fucked up you worry for your long term mental health (no, unexpected Klingonian isn't enough for that), or it tips off your work-life balance too much for your pay grade.
You're moving the goalposts. The language (VB), and the language (Klingonese), are integral parts of the job. Off hours activities are not. If an interviewer lies to an interviewee, they are misrepresenting the job. Surely they will view similar misrepresentation from the interviewee in an equally positive light?
If it were only the interviewer hurt by those lies, I would consider it just deserts. Sadly, the interviewee also suffers in the form of health and economic loss.
Guess I just don't have enough hatred for learning new stuff.
Looking before you leap is hatred of new stuff? If you really loved learning new stuff, you'd let every new hire turn your established processes inside out.
Any idiot can make code work.
Wow. Haven't worked with many idiots, have you? Stretching the definition of "works" to "compiles" wouldn't cover all of them.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
The difference being, you get paid for a job. As long as they pay you as much as was agreed to, it doesn't matter much what you waste your 40 hours a week on in particular. The exceptions are when there's a risk of bodily harm, or the job is so fucked up you worry for your long term mental health (no, unexpected Klingonian isn't enough for that), or it tips off your work-life balance too much for your pay grade.
You're moving the goalposts.
Am I? Are we not talking about whether hiding the need to learn brand new language for the new job acceptable?
The language (VB), and the language (Klingonese), are integral parts of the job. Off hours activities are not. If an interviewer lies to an interviewee, they are misrepresenting the job. Surely they will view similar misrepresentation from the interviewee in an equally positive light?
Interview is a game of lies. They lie that you'll like the project, and you lie that you'll do a good job. After getting hired, the only thing that matters is that they pay you as agreed and that you deliver features kinda sorta as agreed. Plus some very minor stuff like the coffee tasting good and the tech stack not driving you insane.
If it were only the interviewer hurt by those lies, I would consider it just deserts. Sadly, the interviewee also suffers in the form of health and economic loss.
Health? Is your psyche really too weak to face such abominations as COBOL, RPG or Asterisk? I'd suggest a different career then.
Economic? Are you getting paid as agreed? Then what's the problem?
Guess I just don't have enough hatred for learning new stuff.
Looking before you leap is hatred of new stuff?
No. Refusing an offer just because you're not familiar with the tech stack is (I assume you want to know entire tech stack beforehand so you can refuse early if you don't like it.)
If you really loved learning new stuff, you'd let every new hire turn your established processes inside out.
Talk about moving goalposts.
Any idiot can make code work.
Wow. Haven't worked with many idiots, have you?
Any idiot can make code work eventually, at least on the happy paths. Sample size: several dozen idiots at my old workplace. Also, India.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
When style guides are substituted for code reviews, as has been my experience
That only reinforces my view that your former employer was a cesspool of incompetence. Your problem is that you're deriving general rules from your experiences at a workplace that was crap for completely different reasons.
Because the rest of your rant only focuses on very specific styles you dislike.
Would you care to enlighten me on why the acronym rule exists or do you agree that it's arbitrary?
And to take a page from your book, is your only argument for camel casing that everybody should use it because everybody uses it?
I'm not arguing for or against a particular set of rules. I'm arguing for consistency.
Really, unreadable is subjective.
Which is why you stick to whatever style the project you're working on already used instead of having endless discussions about aesthetics.
[...] If you're happy with me working at 70% capacity, fine, but that hasn't been the case.
Just use a formatter and/or configure your IDE correctly. It's not that hard.
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Basically, you're saying that everyone who ever wrote a book on software engineering is lying and code and requirements don't constantly change. Also, all the statistics that say you spend more time reading code than writing it are also lying. That's a very, very unique view.
I'll answer this with an anecdote [...]
The IT anecdote seems to have nothing to do with the topic.
When you start from a faulty premise, you can draw all sorts of conclusions that aren't right.
So you're saying almost everyone who writes books about software engineering is making the same mistake and you're the only one that noticed? Come on!
That's what happens with these books. When you're told all software has bugs, you're supposed to think defensively to mitigate their effects, not justify sloppy practices and half-baked logic because nothing really matters. When you're told that requirements change, you're supposed to write code that's flexible, not rewrite tightly coupled routines every time it changes because nothing else can be done.
It sounds like you've never actually read one of those books, because you're not describing their contents even remotely correctly.
Statistics that say you spend more time reading code that writing it? [...] It also discounts that you read as you write, And that it's code six months ago, not six minutes ago, that takes effort to get back into [...]
I don't know what magic projects you're working on that don't require constant maintenance, but maybe I should submit my resume to you. I'd love to work on that write-once code you're apparently working on.
Seriously, though, what you're saying is the exact opposite of my professional experience and that of many others. I spend at least 60% of my time reading code that was written more than 6 months ago.
@Zenith said:
The goal of a programmer should be to write code once and never have to look at it again.
The goal of every job is to do it once and move on. That's how we accumulate over the long term.
Ever heard the phrase "don't reinvent the wheel?"
Yes, and that's not what it means.
[...] The most defining attribute of SCRUM to me isn't the stand-up but the do-over. Don't plan ahead or think defensively. Just slap together what works this instant and wait for somebody to file a data corruption ticket.
Are you somehow trying to say that any iterative development process is flawed here? I honestly cannot tell and I don't understand why anyone would claim that unless he or she severely misunderstands said process. And why are we talking about SCRUM all of a sudden anyway?
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Interview is a game of lies. They lie that you'll like the project, and you lie that you'll do a good job. After getting hired, the only thing that matters is that they pay you as agreed and that you deliver features kinda sorta as agreed. Plus some very minor stuff like the coffee tasting good and the tech stack not driving you insane.
The cynicism is strong in this one.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
coffee tasting good
Search returned no results.
-
@gleemonk
200 lines nested 10 deep.Eugh, just gave me nightmares man.
-
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
coffee tasting good
Search returned no results.
What about a tech stack that doesn't drive you insane?
-
@JBert said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Interview is a game of lies. They lie that you'll like the project, and you lie that you'll do a good job. After getting hired, the only thing that matters is that they pay you as agreed and that you deliver features kinda sorta as agreed. Plus some very minor stuff like the coffee tasting good and the tech stack not driving you insane.
The cynicism is strong in this one.
It served me well over the years.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
coffee tasting good
Search returned no results.
What about a tech stack that doesn't drive you insane?
No results there, either, but that may be influenced by insanity being a pre-existing condition.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
What about a tech stack that doesn't drive you insane?
Is there such a thing?
-
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
coffee tasting good
Search returned no results.
Shouldn't've used Yahoo!
-
@loopback0 It doesn't matter how good or bad the search engine is, if the thing you're searching for doesn't exist.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
I'm pretty sure it was a thing in early 90s
Mid to late 90s, really. Kicked off after the internet started being commercialised (though “email” predates that by quite a bit), and only really fell out of favour after the dotcom crash of 2001.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Code needs to be judged by how it works and not how it looks.
It needs to be judged by what it does, how it works, and how it looks. The first is the high-level operational view, and what value it delivers to others. The second is the semantic view, and concerns how effective it is at delivering its' outputs. The third is the syntactic view, and concerns how easily it is communicated to your peers (and your future self, who might as well be a different person and who knows where you live). All are valid and all are things you should care about.
Code that does nothing good is valueless. Code that delivers good value in a horrible way is not good either. Code that delivers good value effectively but which is a visual mess, well that's not code that's likely to survive because the next set of eyes to look at it is likely to rewrite it all from scratch anyway, or do major changes to it without realising.
-
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
Code that delivers good value effectively but which is a visual mess, well that's not code that's likely to survive because the next set of eyes to look at it is likely to rewrite it all from scratch anyway, or do major changes to it without realising.
I'd say the biggest risk with that kind of code is not that it doesn't survive, but that nobody ever dares to touch it, even when they find bugs in it or when it should be changed because of a new feature request. Whatever that code does then becomes an immutable part of the specification of your software.
-
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
Code that delivers good value effectively but which is a visual mess, well that's not code that's likely to survive because the next set of eyes to look at it
I guess you never read the front page?
-
-
@Zerosquare said in When the reviewer doesn't understand my Javascript it's his fault:
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
Code that delivers good value effectively but which is a visual mess, well that's not code that's likely to survive because the next set of eyes to look at it
I guess you never read the front page?
The what?
-
-
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
@loopback0 It doesn't matter how good or bad the search engine is, if the thing you're searching for doesn't exist.
Sure does. A shitty search engine will happily provide irrelevant results.
-
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
do major changes to it without realising.
I approve of the nice euphemism you have there.
-
@Carnage said in When the reviewer doesn't understand my Javascript it's his fault:
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
@loopback0 It doesn't matter how good or bad the search engine is, if the thing you're searching for doesn't exist.
Sure does. A shitty search engine will happily provide irrelevant results.
A shitty search engine may also provide you exactly what you want.
After two days.
-
To get back on topic: I agree that consistency of code is important. On the other hand I'm doubtful on the usefulness of formal style guides and I hate auto-formatters. As I see it, what is most important about code formatting is that it supports the structure of the code and provides the necessary visual clues to help parsing it. Thus deciding what is "good" requires an intricate understanding of the semantics and context of the code in question. This is simply beyond the capabilities of any automatic tool. The only thing the automaton can do is in fact erase all this information and turn the code into unreadable, uniform character soup.
One example that always annoys me is visual studio's auto-formatting putting spaces around all operators, thus for example turning
2*x + 3*yinto2 * x + 3 * y. Thanks VS for adding those superfluous spaces and thus completely obliterating the operator precedence
Yes, this trivial example could be solved by adding knowledge about operator precedence to the formatter; but in more complex cases the required knowledge to get the most readable formatting depends on insights about the code base and the intent of the code in question. For example, I generally try to keep trivial sanity- / null-checks as short and unobtrusive as possible, as they are in general very easy to identify and only distract from the actual useful work of the code. There's no way an automated tool can cope with subtleties like these.Formal style guides may be helpful but should never taken for gospel: if the style guide mandates something that is actively contrary to the semantics of the code, I say ignore it and make sure what you write is readable. I also don't really see very much need for them. Just look through the existing code and make sure your new additions blend in with that, it really isn't so difficult.
Writing readable code requires attention, care and good judgement by the writer, there really isn't any way around that. If your programmers are tools, you can layer as many other tools on top of them as you want you still won't get good code.
-
@ixvedeusi I can see why some teams might want to use an informal style guide instead of automatic tools. The downside, however, is that you'll have more discussions about style in your code reviews, then, which is something that I usually like to avoid. If you have a git hook or CI stage which checks the style automatically, the human reviewers can focus on the stuff that actually matters.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
If you have a git hook or CI stage which checks the style automatically, the human reviewers can focus on the stuff that actually matters.
I can see your point and concede that it has some merit; I'm mostly replying in order to snidely remark that in my opinion code readability is part of the "stuff that actually matters" in a code review
But yeah, having never-ending discussions about it kinda gets old quickly and it can be handy to have some formal way to settle the affair and stop going in circles. Luckily we don't have that problem very much at my current work place.
Of course if you use an automatic tool to solve this you'll have to live with that tool making the code unreadable instead.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Your problem is that you're deriving general rules from your experiences at a workplace that was crap for completely different reasons.
Not just a workplace. At least three. Potentially two more but I never got to write a line of code there.
Which is why you stick to whatever style the project you're working on already used instead of having endless discussions about aesthetics.
When the project is all over the place, has no written rules, and is an operational mess and you're still being beaten over the head for aesthetics?
Just use a formatter and/or configure your IDE correctly. It's not that hard.
Does nothing to solve the readability problem. Tools don't reformat code when you pull from TFS. Visual Studio does it on pastes and new lines.
The IT anecdote seems to have nothing to do with the topic.
Except it does. Did you see this line?
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
When you start from a faulty premise, you can draw all sorts of conclusions that aren't right.
So you're saying almost everyone who writes books about software engineering is making the same mistake and you're the only one that noticed? Come on!
One, they're trying to sell you something. They want you to buy this book so they tell you what makes you feel good. "All software has bugs" translates to "it's not your fault you write buggy software because software is hard." If there's an answer you want to hear, there's a book that will give it to you. It's especially true books trying to sell you a process,
Two, I haven't finished my book.
Three, a bad workplace around here gives copies of "How to Win Friends and Influence People" to new hires. I stopped reading it when it became clear that it just kept saying "always praise other people's work even when it's terrible."
I don't know what magic projects you're working on that don't require constant maintenance, but maybe I should submit my resume to you. I'd love to work on that write-once code you're apparently working on.
Well, three of them are being scheduled to be replaced by Indian garbage eventually because they weren't written in MVC and don't generate enough support tickets. Another sat unchanged for at least 10 years because it worked and I guess nobody else knew how to use socket buffers either (see programming confessions thread).
The others, well, thanks, but I don't think you'd adhere to my style guide. Since I'm playing interviewer here, I will consider absolutely none of your other qualifications. Don't feel too bad, though; there are only two people on Earth that I'd trust with my personal projects.
Seriously, though, what you're saying is the exact opposite of my professional experience and that of many others. I spend at least 60% of my time reading code that was written more than 6 months ago.
I don't. I really don't. That's why I could get more done in a week than some developers get done in a year. I worked really hard to do it right the first time. I talked to end users, wrote libraries, was consistent with error handling, kept layering to a minimum, documented every function I wrote. This is why the projects worked. I knew what was being done, didn't rewrite generic code, could track down errors quickly. I didn't have to use a debugger until I was in this industry for over a decade.
This is why I bristle at being told how to do my job by people that don't do any of that and instead fixate on capitalization and bracket placement. It's maddening. Their application is down 8 hours every week, sometimes during peak business periods, for reasons that have nothing to do with a style guide. Instead of accepting help and learning from it, they go into attack mode. That's not my fault.
Are you somehow trying to say that any iterative development process is flawed here? I honestly cannot tell and I don't understand why anyone would claim that unless he or she severely misunderstands said process. And why are we talking about SCRUM all of a sudden anyway?
There is iterative like adding tools to a Swiss army knife and then there is iterative like building a bicycle. At any stage in the process, you have a working knife. However, you do not have a working bike until the end.
Half of my experience with iterative development has been the bike model (the other half were successful projects). They take a legacy system that works fine, claim they don't have resources to update it, and then then spend more resources on a rewrite. The Indians spend three years getting to 30% capacity and 70% fuckups. They shut the legacy system off. Two years later, the Indians are at 60% capacity and 40% fuckups. Then somebody comes along and says they don't have enough resources to finish so they need to spend more resources on a rewrite. Done the same exact way.
The point is that you're just playing beta tester forever. It's never right. That makes "continuous improvement" a sick joke, especially when it drags out for years and years. But that's what you get when you hire and manage wrong. And I think giving too much weight to a style guide is hiring and managing wrong.
Personally, even as I write this, I can say that I don't have an ego. I've worked with IT people that have egos. They can't handle questions and don't solicit suggestions. It's why I've been looking lately. Too much stuff doesn't work and they're preoccupied with witch hunts. I liked having people bring me questions and suggestions. Find a bug in my program? If you brought me enough information, I'll fix it right now and thank you for finding it. But if your "bug" is about style, keep it to yourself. I don't harass other people about style and expect the same courtesy from them. Is that really so much to ask?
If I never have another "professional" programming job in my life, I think I can live with that, I can always write a book....
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Which is why you stick to whatever style the project you're working on already used instead of having endless discussions about aesthetics.
When the project is all over the place, has no written rules, and is an operational mess and you're still being beaten over the head for aesthetics?
You're kind of arguing for me and against yourself now. With automated style checking, one part of the mess would have never gotten quite as bad and at least the code style rules would be apparent.
So you're saying almost everyone who writes books about software engineering is making the same mistake and you're the only one that noticed? Come on!
One, they're trying to sell you something. They want you to buy this book so they tell you what makes you feel good. "All software has bugs" translates to "it's not your fault you write buggy software because software is hard."
Again, none of the books I'm talking about say anything remotely like that. In fact, they usually say the exact opposite.
It's especially true books trying to sell you a process,
Why are you changing the topic to development processes again? Maybe you're thinking about Extreme Programming, misunderstanding its principles and think that's what I'm talking about? I'm not.
Three, a bad workplace around here gives copies of "How to Win Friends and Influence People"
That's not a book on software engineering, is it?
Seriously, though, what you're saying is the exact opposite of my professional experience and that of many others. I spend at least 60% of my time reading code that was written more than 6 months ago.
I don't. I really don't. That's why I could get more done in a week than some developers get done in a year. I worked really hard to do it right the first time. I talked to end users, wrote libraries, was consistent with error handling, kept layering to a minimum, documented every function I wrote. This is why the projects worked. I knew what was being done, didn't rewrite generic code, could track down errors quickly. I didn't have to use a debugger until I was in this industry for over a decade.
This is why I bristle at being told how to do my job by people that don't do any of that and instead fixate on capitalization and bracket placement. It's maddening. Their application is down 8 hours every week, sometimes during peak business periods, for reasons that have nothing to do with a style guide. Instead of accepting help and learning from it, they go into attack mode. That's not my fault.
Well, if you're so much better than your co-workers that you always get to work on shiny new projects, good for you, but that doesn't mean your experience is representative or that your co-workers and/or successors won't have to read your code later.
Are you somehow trying to say that any iterative development process is flawed here? I honestly cannot tell and I don't understand why anyone would claim that unless he or she severely misunderstands said process. And why are we talking about SCRUM all of a sudden anyway?
There is iterative like adding tools to a Swiss army knife and then there is iterative like building a bicycle. At any stage in the process, you have a working knife. However, you do not have a working bike until the end.
Half of my experience with iterative development has been the bike model (the other half were successful projects). They take a legacy system that works fine, claim they don't have resources to update it, and then then spend more resources on a rewrite. The Indians spend three years getting to 30% capacity and 70% fuckups. They shut the legacy system off. Two years later, the Indians are at 60% capacity and 40% fuckups. Then somebody comes along and says they don't have enough resources to finish so they need to spend more resources on a rewrite. Done the same exact way.
The point is that you're just playing beta tester forever. It's never right. That makes "continuous improvement" a sick joke, especially when it drags out for years and years. But that's what you get when you hire and manage wrong. And I think giving too much weight to a style guide is hiring and managing wrong.
And again, you're blaming your bad experiences in a shitty, mismanaged work environment on the tools and the processes they claimed to implement (and probably didn't) instead of the shitty management.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
its'
FTFY
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Well, if you're so much better than your co-workers that you always get to work on shiny new projects, good for you, but that doesn't mean your experience is representative or that your co-workers and/or successors won't have to read your code later.
I think I've just gotten fed up with other people getting to keep starting fires for other people to put out and getting to promote their processes as best practices because everybody else is too busy fighting fires. Projects I've had some control over, new or otherwise, turned out fine. Projects where I was thrust into a raging inferno with handcuffs and concrete boots, not so much. I don't take well to responsibility without authority.
Or micromanagement. Like forcing a style. Would you like to come sit next to me and make sure I type the Mavis Beacon way too? How about my desktop, maybe select the resolution and font that works for you while you're at it? It's absurd.
If somebody cares so much about my style, they can ask me to write a function in the interview! Just skip one of the meandering "hur dur, ware do u c urself in 5 yeerz" type questions. The answer to that is always "working here, if you let me deliver what I said I could." Go ahead and turn down a really great idea because I typed it "wrong." Just do it while I have a choice.
That's not a book on software engineering, is it?
No, but was handed out to me upon starting a software development job for some reason. Even though I don't value anything it says, I have seen where disregarding it has had consequences. Testing a do-not-call website and managing to perform a DOS attack by holding down the enter key, for instance. I knew I should've said "great job, Jose, keep up the outstanding work!" but decided not to. Don't ask me to test something if you don't want me to break it.
But I actually have read a few development books and follow pertinent blogs. I happen to like The Old New Thing. Actually, I see Windows compatibility as very much at odds with industry "best practices." Nor does the .NET 4.0 reference instill me with confidence that Microsoft's style guide is anything to write home about.
And again, you're blaming your bad experiences in a shitty, mismanaged work environment on the tools and the processes they claimed to implement (and probably didn't) instead of the shitty management.
No, I do blame mismanagement. It's just that I see autocratically forcing a style as part and parcel of mismanagement. Look, trying to retroactively push a style on a broken codebase has no value, nor does rejecting a working fix over style quirks. Even once you've ironed out all of the functional issues (haha), applying a style at that point is completely superficial. When you combine that with problems that a style can't fix, and its weaponization potential, and the complete disregard for the subjectivity of readability, it's really difficult to make an argument for it.
At some point, if you've seen enough projects and products that all claim to be following "best practices" and don't like the results, it's completely logical to question, if not reject, those tools and processes. If you can't do that, you run the very real risk of falling into the "this time is different" trap. Some people can handle being bottled up like that. I can't.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
No, I do blame mismanagement. It's just that I see autocratically forcing a style as part and parcel of mismanagement.
I think you're overdramatizing. Running a formatter before you check in / push / whatever your code is not time-consuming.
At some point, if you've seen enough projects and products that all claim to be following "best practices" and don't like the results, it's completely logical to question, if not reject, those tools and processes.
And I think you're over-generalizing here, although that's really a completely separate discussion, as I never wanted to discuss development processes in general.
I get your frustration. I really do. I just think it's making you draw wrong conclusions about software development in general.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
I despise this "readability" mantra.
Today's programmers seem to be "write only".If you hate the latter, why are you against the former?
You know, like nobody is capable of reading code anymore unless it is served to them neatly folded on a silver platter with a fucking instruction manual, dictionary and a couple of geisha next to it for massaging their temples to reduce the stress of having to figure something out on their own.
Everybody including me hates people who are unable to try and figure out things on their own and use a debugger to do so, if necessary. (In fact, nothing infuriates me more than people who refuse to use debuggers.) I'm not arguing for making code accessible to lazy code monkeys, I'm arguing that people should act like professional engineers and adhere to the standards their team agreed upon instead of defending laziness and sloppiness.
And what is stopping programmers from reading and changing code written by others?
Nothing, but clear and consistent code makes it easier to do so and also won't annoy the next person who looks at it.
Why does everybody act like I'm defending horrible and lazy developers? I'm not, you shouldn't hire them in the first place, if possible. I dislike code monkeys as much as everyone else.
The Front Page - Wikipedia
