When the reviewer doesn't understand my Javascript it's his fault
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Because you (like many others) seem to be putting form (code style, readability) over function (whether it satisfies business requirements, works without errors, has adequate performance)?
No, I'm not. These two goals are not mutually exclusive - in fact, they're completely orthogonal.
Because satisfying said form is easier to accomplish by those horrible and lazy developers than actual coding and thus does nothing to weed them out but instead encourages mindless drones who follow orders but can't do anything on their own?
Who suggested to judge candidates by their code style? I certainly didn't.
BTW: There's another type of bad developer that hasn't been mentioned yet and can be almost as annoying as code monkeys: Cowboy coders, who don't care about anything else except that their code somehow works.
If I'm defending mindless code monkeys, then you're defending cowboy coders. Because that's what people who don't care about readability at all ultimately are.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Running a formatter before you check in / push / whatever your code is not time-consuming.
I didn't say it was.
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
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.
Depends on how you define "the team" and "agreed." If I'm a part of the team, and I don't agree, did the team agree? The assumption here is already that the style came from the team and not some clown manager's copy of Buzzword Monthly. What about the type of agreement? Natural or extracted under threat of disemployment? This is why I want style disclosed at interview time, so I can choose whether or not to work for you as opposed to choosing whether or not to make my mortgage payment.
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Why does everybody act like I'm defending horrible and lazy developers?
Because it's horrible and lazy developers on the other side of my struggle. I realize that's not your fault. Doesn't mean I can't criticize the imposition of a style.
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
Who suggested to judge candidates by their code style? I certainly didn't.
Since style isn't disclosed at interview time, you're not judging candidates but employees. "Gee, Rick, you solved that bug that took a nickel off everybody's balance every time they refreshed the page, but can you fix lines 21, 24, 34, 67, 68, 71, 89, and 93 to put the brackets in the right place or pack up your things and security will see you out?"
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Or micromanagement. Like forcing a style.
The more people you have on the project, the better it is to enforce some style rules. Basic ones. Otherwise readability really nosedives as every developer seems to have radically different ideas about what actually constitutes a good style that they ought to use for everything. With two developers, it doesn't matter much. Once you've scaled up to ten, it's an essential tool to support general readability.
And I've not seen people being particularly cramped by style enforcement. (I admit I was careful in setting the style in use to be one very close to our average practices; some places have rules that are far fussier and sillier. I know this because I turned those offβ¦)
Strict auto-formatting can also work too, but only if you start doing it early in a project and everyone uses it. In that case, you simply stop trying to be creative in how you lay things out and concentrate on the higher-level meaning of things.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Operator precedence is encoded in the language's compiler (parser/lexer), not by your omission of of spaces.
No shit Sherlock. The problem is when the compiler interprets the code differently than the reader, which is why the spacing should match what the compiler actually understands.
-
@Zecc said in When the reviewer doesn't understand my Javascript it's his fault:
It's a purely stylistic choice.
I think I see what you're getting at.
While I have stylistic opinions, I'd trade it in for One Way Of Doing Things. It would solve things like...
@Zecc said in When the reviewer doesn't understand my Javascript it's his fault:
Languages providing their own linter
I mean, I agree. IMO though the amount of requirement for a linter is limited to non-existent if you've got one way of doing things to rule them all. This is just speculation though.
So regarding my earlier point about operator/variable whitespace, I only care because this is the world we live in, where I have to choose.
I'm even less opinionated about spaces vs tabs. Either we use whatever is already being used, or spaces if greenfield unless people really don't want to for some reason, but using both is an insanity I would go to war and die over (mild exaggeration).
@Zecc said in When the reviewer doesn't understand my Javascript it's his fault:
@Shoreline said in When the reviewer doesn't understand my Javascript it's his fault:
Is it because of the "sane" part? :P
Good joke btw.
Thanks, I'm here all week. I get evicted Monday.
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
cough Perl
cough Nightmares.
-
@Shoreline said in When the reviewer doesn't understand my Javascript it's his fault:
about spaces vs tabs
Use spaces if you or your co-workers are sloppy pigs who can't be bothered to care about what they type, or if you have a "helpful" IDE that pisses all over your carefully-designed white space. If you care about doing things The Right Way
, use tabs for indent and spaces for alignment as the Gods of Code intended.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
I don't take well to responsibility without authority.
I am reliably angry when these lack a 1:1 relationship.
Authority without responsibility: Blamegaming asshole whose "solution" to every issue is "you fix this right now or consequences which reflect on you".
Responsibility without authority: "Can I get updates?" silence "What are we doing today?" silence "Please find fix for problem X" "Problem X doesn't exist. Pedantically different problem Y exists." "Fine. Please fix problem Y" "Again, problem X doesn't exist..."
Reliably angry.
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
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.
They're lying or they're wrong. Either way they're not following best practices. I realise you can't necessarily know that.
I've worked in about 9 places.
- I've worked in about 6 places which claimed to follow some kind of Scrum/Agile/Whatever methodology:
- I've worked in at least two places that had a tester who was asking me - the developer - how they should test my code.
- I've worked in 1 place where they used development velocity rather than telling me how long I had to do the development or demanding estimates.
- I've worked in 3 places which habitually both told me how long I had and demanded estimates.
- I went to a sprint planning meeting where the lead went through a couple of tickets before the meeting got "timeboxed" (which is a fancy way of saying prematurely-completed, which is also how I would describe my sex life), then after the meeting asked me for an estimate on a ticket we'd estimated in the meeting, after we'd all sat there playing estimate poker.
I mention these because license to rant-disguised-as-examples.
Your dudes might think they're following "best practices", when their application falls short.
IMO the problem is the modern practise of client-driven development, where the client says jump, therefore you all jump, even though tomorrow would be a more optimal time to jump, as you're all too busy to jump right now. Also that wasn't the plan, but the client says so, so you do it.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Depends on how you define "the team" and "agreed." If I'm a part of the team, and I don't agree, did the team agree?
Usually, people are supposed to accept majority decisions when working in a team. You seem to be objecting to that.
And in the case of code style, I've already argued that you should just accept whatever the existing code of each project uses, because the details ultimately don't matter as long as you're consistent.
What about the type of agreement? Natural or extracted under threat of disemployment? This is why I want style disclosed at interview time, so I can choose whether or not to work for you as opposed to choosing whether or not to make my mortgage payment.
"Gee, Rick, you solved that bug that took a nickel off everybody's balance every time they refreshed the page, but can you fix lines 21, 24, 34, 67, 68, 71, 89, and 93 to put the brackets in the right place or pack up your things and security will see you out?"
Sorry, but now you're just sounding like an anarchist lunatic. Contrary to what you seem to believe, not every single majority decision you disagree with is a horrible infringement of your civil rights. Especially if we're talking about running a goddamn code formatter. It doesn't take a considerable amount of time, it doesn't hurt you or your productivity in any way and it's also not the end of the world if the result is not what you personally find most aesthetic.
Seriously, if you refuse such simple requests as a matter of principle, you're just a horrible co-worker.
Edit: Sorry if I'm overly harsh, but I simply don't know how else to respond to what you just wrote. You're overreacting and acting like using a formatter is a traumatic experience instead of a simple act of courtesy.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
@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.
Apart from my first job, where there was a never ending war about where { should go, and single/multiple returns, I've actually never had that. Even at that job, those discussions were in a forum dedicated to maintaining guidelines and such stuff. Code reviews was never about arguing about styles.
In the rare occurrence where formatting is brought up in code reviews it's been to suggest a way to format the code that is clearer, and only when it's an obvious improvement.
-
@Carnage
I think it all depends on team size and the team members. If you're working in a large team where those unnecessary discussions happen a bit too often or with a lot of college graduates, a tool and formal guidelines usually help avoid arguments and improve productivity. If you're working with a small team of experienced professionals who all more or less agree on what "good code" looks like and have learned to review their own changes before submitting a PR, then tools are entirely optional.
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Personally, even as I write this, I can say that I don't have an ego.
If I never have another "professional" programming job in my life, I think I can live with that, I can always write a book....
Cue another author who gets angry at reviewers.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
@Carnage
I think it all depends on team size and the team members. If you're working in a large team where those unnecessary discussions happen a bit too often or with a lot of college graduates, a tool and formal guidelines usually help avoid arguments and improve productivity. If you're working with a small team of experienced professionals who all more or less agree on what "good code" looks like and have learned to review their own changes before submitting a PR, then tools are entirely optional.I've worked in organizations with everything between 130 developers in the same code base, and me, myself and I. Never really was a problem I had. The large organisation was the one with a forum for guideline work, but it still didn't really creep into the day-to-day work.
At that place, every team got 1 freshly minted developer about once every 6 months for training, and they then were moved out to a new team with a single senior dev, and 5-6 of the freshly trained devs, so there were a fair bit of new people coming through as well.
The general rule of thumb most people kept to was "Keep the new code as similar as the file you're touching as sensible" and no massive style updates because of nightmare merges.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Because you (like many others) seem to be putting form (code style, readability) over function (whether it satisfies business requirements, works without errors, has adequate performance)?
At my company we hire a lot of co-ops, and sometimes have contractors. Since I've been here, I've looked at a lot of code and the correlation is almost always that the code with inconsistent spacing, single letter variable names, etc, is always code that's been slapped together, sometimes pasted from StackOverflow, and sometimes just put in as a one-step-thinking solution to an individual problem without considering any of the rest of the application. It's never been the case that someone wrote well-thought-out, perfectly working code that happened to be unreadable and badly formatted.
I do like this though:
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Team Leader: Can you write code in C#?
Clown: Oh yeah! I see sharp allright! I sat on a top of a building once shooting crows, but the police were too busy teargassing me to ask what I was doing...
Team Leader: Ok, ok... have you ever used Git?
Clown: No but my Pa always keeps tellin' me to git gud so I don't get rekt
-
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Doesn't mean I can't criticize the imposition of a style.
I'm constantly criticizing our code style. I hate it. But there's 15yrs and several hundred thousand lines of code. So I follow it.
-
@ixvedeusi said in When the reviewer doesn't understand my Javascript it's his fault:
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Operator precedence is encoded in the language's compiler (parser/lexer), not by your omission of of spaces.
No shit Sherlock. The problem is when the compiler interprets the code differently than the reader, which is why the spacing should match what the compiler actually understands.
Not white space. Parentheses. Redundant parentheses that the compiler doesn't need, because they match the default precedence rules, but which make the precedence explicit to the human reader.
-
@Shoreline said in When the reviewer doesn't understand my Javascript it's his fault:
I've worked in 3 places which habitually both told me how long I had and demanded estimates.
Manglement: How long will it take to do $task?
Engineering: $task will take X time.
Manglement: $task will be done in X/3.
-
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
@Shoreline said in When the reviewer doesn't understand my Javascript it's his fault:
I've worked in 3 places which habitually both told me how long I had and demanded estimates.
Manglement: How long will it take to do $task?
Engineering: $task will take X time.
Manglement: $task will be done in X/3.
-
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
@Shoreline said in When the reviewer doesn't understand my Javascript it's his fault:
I've worked in 3 places which habitually both told me how long I had and demanded estimates.
Manglement: How long will it take to do $task?
Engineering: $task will take X time.
Manglement: $task will be done in X/3.And people wonder why we multiply our estimates by Z. (Z varies since manglement uses different divisors sometimes.)
-
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
Not white space. Parentheses. Redundant parentheses that the compiler doesn't need, because they match the default precedence rules, but which make the precedence explicit to the human reader.
I find on the contrary that parentheses would just be useless noise and thus make this harder to read. I know that
*has higher precedence than+, and if I go into the trouble of actually parsing that line of code I can figure out what it does just fine. But if there's the appropriate visual grouping (i. e. adequately placed white space), I don't need to bother with checking the symbols, I can immediately identify the hierarchy of operations by just glancing at it, and that's helpful for quickly grasping the meaning of the code. On the other hand, if there's two additional sets of parentheses, I now have four additional symbols to identify to figure out what it does, and verify that the parentheses match up as I expect and not actually override the operator precedence.And inb4 "but you can place the spaces wrong and thus obscure the meaning", this is exactly what the code auto-formatter does: It converts the code into featureless character soup with all (helpful or unhelpful) visual clues removed except for the bare, most basic syntax rules (which are almost never what I'm interested in when I'm reading code, the compiler can tell me perfectly well if the syntax is correct).
To me code auto-formatters seem to provide about as much value as those tools to auto-generate doc comments: their output is basically useless and only possibly better than the input if the original coder was absolutely careless; in all other cases the output is worse because it obscures the meaning of the code.
-
@dcon Of course, sometimes no amount of padding will help, because it's "Project will be done by arbitrary deadline that's immovable, regardless of the estimate." Sometimes there's a good reason for the immovable deadline (e.g., product launch at a trade show); sometimes it's "We have decided development takes too long, so we're going to tighten all schedules by Z%," where the trimming is relative to some arbitrary or typical schedule, not this project's realistic schedule.
-
@ixvedeusi said in When the reviewer doesn't understand my Javascript it's his fault:
And inb4 "but you can place the spaces wrong and thus obscure the meaning", this is exactly what the code auto-formatter does
Someone might write
a + b<<1, and the reviewer who depends on spaces to deduct meaning might never notice the bug. And that is not what an autoformatter would generate.
-
@Grunnen said in When the reviewer doesn't understand my Javascript it's his fault:
the reviewer who depends on spaces
The reviewer who depends on spaces is an idiot. The spaces just help getting the initial guess right, so that you don't have to back-track and re-parse the line once you recognize it doesn't say what it looks like.
Are any of you seriously arguing that
2*x + 5*yislessnot more readable than the turned-into-soup2 * x + 5 * yversion? Because that's all I claim: the auto-formatted version is less readable than the correctly formatted version (but of course more readable than an incorrectly formatted version like2 * x+5 * y; and I'd definitely call that one out in a code review).
-
@ixvedeusi I'd argue that
( 2 * x ) + ( 5 * y )gives clarity in a way that doesn't have any risk of suggesting something wrong.
-
@ixvedeusi said in When the reviewer doesn't understand my Javascript it's his fault:
I can immediately identify the hierarchy of operations by just glancing at it
I'm always forgetting the precedence of
&&and||(and I'm sure many others do too) so I find having some extraneous parens there is actually helpful. There's a certain point they're just noise, but they're definitely not useless either.
-
@dcon If the amount of parens turns your math to soup, use more temporaries.
-
@PleegWat said in When the reviewer doesn't understand my Javascript it's his fault:
@dcon If the amount of parens turns your math to soup, use more temporaries.
That too. (I've called people out in reviews on that - "yes, your code is correct, but please break it up because it will be much easier to maintain")
-
@dcon Especially because most smart compilers will emit basically unchanged assembly, especially for basic math. Sure, there are cases where you need to hand-roll things, but those are very few and far between and should be flagged heavily and written/tested within an inch of their lives.
-
@dcon said in When the reviewer doesn't understand my Javascript it's his fault:
I'm always forgetting the precedence of && and || (and I'm sure many others do too) so I find having some extraneous parens there is actually helpful.
Yes these are kinda borderline, and I usually parenthesize them except in the most trivial cases. The ones that really trip me up are
&and|; they have lower precedence than e. g.==(at least if I remember correctly), which I find really counter-intuitive, so they also always get parentheses if there's any chance of ambiguity. but*vs.+are such common and well-known cases that there really shouldn't be any need for parentheses.
-
@ixvedeusi
I've written enough C/C++/Rust that I automatically parse*without spaces on both sides as "pointer".
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
@Zecc And this is why all languages should have a
notoperator.!is horrible because it's so easy to miss next to the opening parenthesis.Only if you're using a proportional-width font.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
I automatically parse * with
outa spacesonbothexactly one sidesas "pointer"FTFM. Using
*for pointer deref or pointer type with no space on either side is seriously
(except if there's no space because there's another *there).
-
@GΔ ska said in When the reviewer doesn't understand my Javascript it's his fault:
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
flaky and broken tests are worse than no tests
I disagree. There can still be value in them. It all depends on how often they break and in what way exactly they break.
I think "flaky and broken" was supposed to describe how often they break and in what way exactly. Saying that they're "flaky and broken" suggests that they break often and seemingly at random, and it's pretty likely that nobody pays any attention when they do.
-
@brie said in When the reviewer doesn't understand my Javascript it's his fault:
Only if you're using a proportional-width font.
Um, no. I've witnessed people miss the negation multiple times and have done so myself. And I've never met a person who doesn't use a monospace font.
-
@dfdub There is, or used to be, someone on here who advocated a proportional font for code. I don't remember who it was, though.
-
@ixvedeusi said in When the reviewer doesn't understand my Javascript it's his fault:
Are any of you seriously arguing that 2x + 5y is
lessnot more readable than the turned-into-soup 2 * x + 5 * y version?For something as simple as that, the spaces don't decrease the readability for me. For something more complex, I will often use () to help seperate sections to make it more clear.
-
@ixvedeusi said in When the reviewer doesn't understand my Javascript it's his fault:
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
I automatically parse * with
outa spacesonbothexactly one sidesas "pointer"FTFM. Using
*for pointer deref or pointer type with no space on either side is seriously (except if there's no space because there's another *there).What about parentheses because you're calling a function pointer or doing something equally sinister? Spaces or no spaces?
Personally, I never put space on the inside of a paren or square bracket. It just doesn't read right.
-
@dcon said in When the reviewer doesn't understand my Javascript it's his fault:
@Zenith said in When the reviewer doesn't understand my Javascript it's his fault:
Doesn't mean I can't criticize the imposition of a style.
I'm constantly criticizing our code style. I hate it. But there's 15yrs and several hundred thousand lines of code. So I follow it.
@dcon might come to say in the future:
I'm constantly criticizing our code style. I hate it. But there's 30yrs and several million lines of code. So I follow it.
-
@GΔ ska said in When the reviewer doesn't understand my Javascript it's his fault:
What about parentheses because you're calling a function pointer or doing something equally sinister? Spaces or no spaces?
Yes, agreed on that one, didn't think of parens. But yeah if you have to use function pointers (or even member function pointers
) all hope for easily readable code is probably lost anyway and adhering to strict formatting rules will not hurt readability.On an unrelated note:
-
@dcon said in When the reviewer doesn't understand my Javascript it's his fault:
I'm always forgetting the precedence of && and ||
&&and||withfalseandtrueare like*and+with zero and non-zero.βββββββββββ¦ββββββββββ¦ββββββββββ¦βββββββββββββββββββββββββββββββββββ¦βββββββββββββββββ β A β B β C β A || B && C == ? β A + B * C == ? β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β false/0 β false/0 β false/0 β false || false && false == false β 0 + 0 * 0 == 0 β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β false/0 β false/0 β true /1 β false || false && true == false β 0 + 0 * 1 == 0 β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β false/0 β true /1 β false/0 β false || true && false == false β 0 + 1 * 0 == 0 β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β false/0 β true /1 β true /1 β false || true && true == true β 0 + 1 * 1 == 1 β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β true /1 β false/0 β false/0 β true || false && false == true β 1 + 0 * 0 == 1 β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β true /1 β false/0 β true /1 β true || false && true == true β 1 + 0 * 1 == 1 β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β true /1 β true /1 β false/0 β true || true && false == true β 1 + 1 * 0 == 1 β β ββββββββββ¬ββββββββββ¬ββββββββββ¬βββββββββββββββββββββββββββββββββββ¬βββββββββββββββββ£ β true /1 β true /1 β true /1 β true || true && true == true β 1 + 1 * 1 == 2 β βββββββββββ©ββββββββββ©ββββββββββ©βββββββββββββββββββββββββββββββββββ©βββββββββββββββββ
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
You can write bad code (i.e an approximation of a solution), and then iterate to improve it.
That's not how iterative development is supposed to work, though, and it's not how it works if done properly. The whole point of such approaches is that you want to avoid bad code by iteratively implementing small parts of the specification correctly. This is better because when you inevitably run out of time, you have a working, stable product and don't have to rush to get it to work at all.
-
@Zecc said in When the reviewer doesn't understand my Javascript it's his fault:
A || B && C == ?
==has higher precedence than&&.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
That's not how iterative development is supposed to work, though, and it's not how it works if done properly. The whole point of such approaches is that you want to avoid bad code by iteratively implementing small parts of the specification correctly.
That's assuming you have a specification.
If your contract with your client does not contain a useful, broad specification that your team can then turn into a complete one, your development methodology is not your biggest problem.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Are any of you seriously arguing ...
YesNo.FTFY. You're not actually arguing what you claim to be arguing, because the paragraph that follows your "yes" does not in any way relate to what my quote is about.
Relying on whitespace which compiler is completely ignoring
Not sure why you mention any of this. The compiler can do with the white space whatever it wants as far as I'm concerned. This is entirely and exclusively about the (human) reader of the code.
and which can be lost to automated reformatting
Why would you want to use such a thing?
to convey
your intendedthe actual operator precedence is beyond retarded.The only intent of this is to help the next person reading that code to interpret it the same way as the compiler.
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
That's assuming you have a specification.
If you don't, your 1. won't work out any better than your 2.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
That's not how iterative development is supposed to work, though, and it's not how it works if done properly. The whole point of such approaches is that you want to avoid bad code by iteratively implementing small parts of the specification correctly.
That's assuming you have a specification.
If your contract with your client does not contain a useful, broad specification that your team can then turn into a complete one, your development methodology is not your biggest problem.
But we're Agile!!
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Fuck the human reader who doesn't know operator precedence of their chosen language. I said that much, haven't I?
I think you have, and it is just as relevant as before (i. e. not at all). It's not about who knows operator precedence and who doesn't. It's about convenience of reading, similar to the problem of people confusing "its" and "it's" or "their" and "they're": I'll still be perfectly able to figure out the meaning (in most cases), but it takes me a split second of reflection each time, and thus it's a bit more tiring and a bit slower. AKA "less readable".
-
@dcon said in When the reviewer doesn't understand my Javascript it's his fault:
But we're Agile!!
I know you're joking, but it's a very common misconception that "agile" means you have no specification and don't think about software architecture. Obviously, if you don't do both, you're not going to succeed. The only thing you really shouldn't do is go into too much detail before you've actually started writing a significant amount of code. Architecture evolves as you write the software and it will turn out that what you initially thought of as the ideal solution probably isn't ideal at all.
-
@Benjamin-Hall said in When the reviewer doesn't understand my Javascript it's his fault:
Especially because most smart compilers will emit basically unchanged assembly, especially for basic math.
It depends on compiler options, and what types you're using. Integer math usually gets fairly well mangled. Floating point might or might not; the effect on algorithms can be profound there (but sometimes it doesn't matter so much).
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
That's part of the process #1 I mentioned, not process #2.
Process #2 is throwing shit at the wall and seeing what sticks (with the client).In any case, what you're describing is a false dichotomy. "Traditional software development" and "half-assedly winging it" are by far not the only options you have.
-
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
"Traditional software development" and "half-assedly winging it" are by far not the only options you have.
Those two are the same optionβ¦
-
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
@dfdub said in When the reviewer doesn't understand my Javascript it's his fault:
"Traditional software development" and "half-assedly winging it" are by far not the only options you have.
Those two are the same optionβ¦
I deliberately didn't put it that way, but I don't disagree.
