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.
There's always "half-assed waterfall" — a detailed spec up front, but incomplete and under constant revision as you're trying to implement it.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Seriously, who gives a shit about your reading convenience and a split second of your time? Get off your self-entitled high horse already and stop pestering others to
work hardermemorize operator precedence to make your own work easier.
-
@HardwareGeek said in When the reviewer doesn't understand my Javascript it's his fault:
There's always "half-assed waterfall" — a detailed spec up front, but incomplete and under constant revision as you're trying to implement it.
I'm more familiar with what I call "waterfall dementia": By the time you're done, the client has forgotten what he initially wanted and blames you for implementing exactly that.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Seriously, who gives a shit about your reading convenience and a split second of your time?
Because saving you that split second is going to cost 20 other people far more time down the line. If it's once-off code, yeah, who gives a fuck. If it's code that is going to be supported for 20 years - you'll save far more time down the line by spending it now.
edit: Oh, I forgot - this thread was about javascript. That will be rewritten multiple times from scratch in the next year. It's only us C++ers that have to worry about 20 year old code.
-
@dcon Also, it isn't always obvious what code is going to have that 20 year lifetime.
-
One time I contributed to an open source project. It was rejected for not prefixing variables with
this.
and for missing a couple of instances of appropriate spacing. Running the formatter and re-pushing took approximately five seconds and did not scar me for life.
-
@levicki
save yourself three characters of typing by refactoring the name of a member variable
Ok
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Now if it would just stop telling me "this function is unused, why not delete it?" for every function I write before I get to insert a call to it somewhere...
I guess it's written for people who write from the outside in, rather than from the inside out (if you see what I mean). In the former style, you make a big function and refactor bits out of it (using the tooling support for that) so there's never any point where an inner support function is unused.
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
@ixvedeusi said in When the reviewer doesn't understand my Javascript it's his fault:
This is entirely and exclusively about the (human) reader of the code.
Fuck the human reader who doesn't know operator precedence of their chosen language. I said that much, haven't I?
Do you really expect me to memorize every single precedence rule of every single operator of each of the 10 languages I use on regular basis?
-
-
@hungrier said in When the reviewer doesn't understand my Javascript it's his fault:
the code with inconsistent spacing, single letter variable names, etc, is always code that's been slapped together,
Yes. Once I'm done beating my code I usually pass through again and reorganize it so it's pretty and makes sense. And commented. Comments are cool.
-
@dkf said in When the reviewer doesn't understand my Javascript it's his fault:
@dcon Also, it isn't always obvious what code is going to have that 20 year lifetime.
It seems to usually be the ugly hacks you throw together without rhyme or reason that just takes care of a temporary need and that will be reimplemented when you get time. Those things last for forever.
-
@Tsaukpaetra said in When the reviewer doesn't understand my Javascript it's his fault:
And commented. Comments are cool.
My favourite project has a style guide where complete docstrings are obligatory, but mid-function comments are unwanted. The reason being that such comments quickly get out of sync with the actual code, so that self-explanatory code should be preferred. What do you think about this?
-
Some people seem to think it's impossible to update the comments when you change the code. I don't know why.
-
@Carnage 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:
@dcon Also, it isn't always obvious what code is going to have that 20 year lifetime.
It seems to usually be the ugly hacks you throw together without rhyme or reason that just takes care of a temporary need and that will be reimplemented when you get time. Those things last for forever.
I distinctly remember from my first job a particularly jarring temporary hack that was there years before me, and stayed there long after I left three years later.
-
@levicki Why is it a heinous crime? Why use a naming scheme instead of just being explicit about it?
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Now if it would just stop telling me "this function is unused, why not delete it?" for every function I write before I get to insert a call to it somewhere...
"This is where I'm declaring the variable. Just let me finish typing the lambda."
-
@levicki said in When the reviewer doesn't understand my Javascript it's his fault:
Prefixing variables with
this.
is a heinous crime.No way am I going to stop using
this.prop = prop;
in constructors.
I have an irrational dislike for function arguments prefixeda_
.
-
@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.
Interesting. A week passed and now you have 10 upvotes, while I've got 0. Not even a free upvote from Tsaukpaetra. I'm not complaining, I just find it really peculiar. It's as if people don't approve of my view, but find it quite funny. As if they didn't partake in casually succumbing into extreme cynicism and depression where you see the world only in the darkest colors like it was the most normal thing to do, like going out for a beer or watching cat videos. Goddamn I feel so Polish right now.
-
#include <translator.h> class Something { private Translator Translator; public Something(Translator Translator) { this.Translator = Translator; } public Translator Translator() { return this.Translator; } }
I'm never exactly sure how much the compiler will allow, and how much of this is logical, clean and normal and how much is confusing and terrible.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Goddamn I feel so Polish right now.
You've just finished a bottle of vodka?
-
@Grunnen said in When the reviewer doesn't understand my Javascript it's his fault:
how much is confusing and terrible
It's code. It's all confusing and terrible by default. That's where you start.
-
@Gąska Your long post is long. Ain't nobody got time for that.
-
@Zecc 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:
Prefixing variables with
this.
is a heinous crime.No way am I going to stop using
this.prop = prop;
in constructors.
I have an irrational dislike for function arguments prefixeda_
.And I have a rational dislike for properties that use camel case instead of Pascal case.
Prop = prop;
all the way.(Obviously, this depends on your language of choice. But for .NET, Pascal-cased properties are idiomatic. And everybody else is just wrong. )
-
@Unperverted-Vixen Rust has the best convention. PascalCase for types, snake_case for everything else. I was skeptical at first, but it makes code surprisingly readable.
-
@Gąska this is the most compelling case for switching to rust that I've heard. I might just give it a try.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Not even a free upvote from Tsaukpaetra.
Sorry.... I don't feel like following this thread very much anymore...
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
I've got 0. Not even a free upvote from Tsaukpaetra.
E_UNIT_TEST_FAILED
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
@Unperverted-Vixen Rust has the best convention. PascalCase for types, snake_case for everything else. I was skeptical at first, but it makes code surprisingly readable.
Actually that's quite common convention as far as number of languages and frameworks using it goes. It is used in Python, it is used in Perl, it is used in quite a few C and C++ libraries, e.g. Gtk+ and everything else Gnome, and probably some other programming environments.
-
@Grunnen said in When the reviewer doesn't understand my Javascript it's his fault:
#include <translator.h> class Something { private Translator Translator; public Something(Translator Translator) { this.Translator = Translator; } public Translator Translator() { return this.Translator; } }
I'm never exactly sure how much the compiler will allow, and how much of this is logical, clean and normal and how much is confusing and terrible.
If you were writing C#, it'd be adhering to correct style, except for the capital
Translator
constructor parameter.
-
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
And I have a rational dislike for properties that use camel case instead of Pascal case. Prop = prop; all the way.
Isn't the whole point of properties to pretend to be fields?
I always found it strange that Microsoft added properties, for which the only practical reason is they allow adding functionality to what was a field in previous release without having to modify the using code, and then differentiate them with naming convention and require that fields should only be made public by wrapping them in a property, so that it has no useful advantage over just creating getter-setter pairs (trivial getter and setter injection could have been done by annotation for the same level of syntactic convenience).
Of course while fields pretend to be fields syntactically, they are actually compiled to a getter-setter pair (and similarly for events), so it would be API-compatible, but not ABI-compatible. But if the desire is to keep ABI compatibility (sometimes yes), why create the mostly useless API compatibility option?
-
@Bulb said in When the reviewer doesn't understand my Javascript it's his fault:
differentiate them with naming convention
Field Pascal
public class MessageQueue { public static readonly TimeSpan InfiniteTimeout; } public struct UInt32 { public const Min = 0; }
-
@Gąska Hm, back when I actually did something with C# I am pretty sure we had (private) fields camelCase. Of course there is no way to see what the fields are named in standard library (since everything visible and documented is properties) and we might have simply misunderstood or misremembered the rules. If it's just locals that starts with lowercase, it makes more sense.
-
@Bulb said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska Hm, back when I actually did something with C# I am pretty sure we had (private) fields camelCase.
Not many people bother to read official guidelines. I have learned it myself only after Visual Studio started bugging me about coding style violations.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
@Bulb said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska Hm, back when I actually did something with C# I am pretty sure we had (private) fields camelCase.
Not many people bother to read official guidelines. I have learned it myself only after Visual Studio started bugging me about coding style violations.
The guidelines don't match their own programming guide example:
-
The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines, and public or protected instance fields are not allowed by the member design guidelines.
(This post doubles as another proof that not many people bother to read official guidelines - including yours truly, who's citing official guidelines right here.)
-
@Gąska I also think the rules are consistent with “everything that is part of the interface starts with capital letter”, and that is another rules that makes some sense. And in Go it is part of syntax where initial capital is what makes things public—IIRC I've seen it in some other language too.
-
@Bulb said in When the reviewer doesn't understand my Javascript it's his fault:
I also think the rules are consistent with “everything that is part of the interface starts with capital letter”, and that is another rules that makes some sense.
The big weakness of that convention is that it becomes harder to visually distinguish types from names. Which is why I don't like it at all.
-
@dfdub Me neither. It follows I don't like the .NET one either. I am just saying it is consistent with .NET standard library in case somebody does.
-
@Bulb said in When the reviewer doesn't understand my Javascript it's his fault:
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
And I have a rational dislike for properties that use camel case instead of Pascal case. Prop = prop; all the way.
Isn't the whole point of properties to pretend to be fields?
Depends on what you mean by "pretend". They provide a abstraction where consumers can treat them like they would fields, while the producer can implement it however they want (and make changes over time) without impacting consumers.
I always found it strange that Microsoft added properties, for which the only practical reason is they allow adding functionality to what was a field in previous release without having to modify the using code, and then differentiate them with naming convention and require that fields should only be made public by wrapping them in a property, so that it has no useful advantage over just creating getter-setter pairs (trivial getter and setter injection could have been done by annotation for the same level of syntactic convenience).
Properties were in C# 1.0; they weren't some new addition later. Using them instead of getter/setter methods feels cleaner. And making them be separate syntax from methods encourages library developers to keep them lightweight.
Of course while fields pretend to be fields syntactically, they are actually compiled to a getter-setter pair (and similarly for events), so it would be API-compatible, but not ABI-compatible. But if the desire is to keep ABI compatibility (sometimes yes), why create the mostly useless API compatibility option?
Going from fields to properties breaks ABI compatibility. But if library authors only use properties in their public API to start with, then that's obviously not an issue. The library author can change it from a simple getter of a backing field to some monstrosity that pulls data from five different databases, and it will still be an ABI-compatible replacement for the consumer.
-
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
Depends on what you mean by "pretend". They provide a abstraction where consumers can treat them like they would fields, while the producer can implement it however they want (and make changes over time) without impacting consumers.
I mean it's just a syntactic sugar over getters and setters.
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
Properties were in C# 1.0; they weren't some new addition later.
I am not talking about feature, but about instance in each particular interface.
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
Using them instead of getter/setter methods feels cleaner.
This is where I strongly disagree. It feels completely pointless.
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
And making them be separate syntax from methods encourages library developers to keep them lightweight.
Except they don't anyway. Or at least you can't trust them to too much.
@Unperverted-Vixen said in When the reviewer doesn't understand my Javascript it's his fault:
But if library authors only use properties in their public API to start with, then that's obviously not an issue.
But no point either. The interface could have had getters and setters (like most do in Java) and it would work just as well and the language would save a bit of complexity.
-
@Bulb there's one more nice thing about properties - they group the getter and setter under a single entity. It doesn't usually matter, but sometimes it does - for example, for data binding like in WPF. If you had getter and setter as two separate, semantically independent entities, then each time you'd want a two-way data binding (which is the most common kind of binding), you'd have to separately provide getter and setter. And that wouldn't even be enough, because the update events that are necessary to propagate property changes, need to carry information about which property changed, and the listener needs a way to tell whether the property from the event is the same as in the binding they have. So each binding would need a getter, a setter, and the property identifier that, since getter and setter are separate independent entities, cannot be inferred from them. And if you would've ever made a mistake and paired a getter with wrong setter, or with a wrong identifier - oh boy, it would be sooo fun to debug.
Property encapsulates all three elements - getter, setter and identifier - into a single neat package, so that you cannot get it wrong. Also, reflections.
-
@Gąska I don't think properties are first class constructs in the underlying runtime anyway. As far as I can tell it's just name and it gets the
Get_
andSet_
prefixes. Yeah, the syntactic sugar makes sure you won't have a typo in it, because you don't write the names separately.
-
@Bulb said in When the reviewer doesn't understand my Javascript it's his fault:
@Gąska I don't think properties are first class constructs in the underlying runtime anyway. As far as I can tell it's just name and it gets the
Get_
andSet_
prefixes.Well, on one hand, yes, the bytecode contains those proxy methods and it's them that actually get called on property access. On the other hoof, they are certainly a distinct element of a type definition, and you can enumerate and operate on them directly via reflection API - even across languages. So it's not just a C# feature, but a general CLR feature.
-
@levicki 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 really expect me to memorize every single precedence rule of every single operator of each of the 10 languages I use on regular basis?
Do I expect you to troll people on the forum? Do I expect you to boast about skills you don't have? Does the sun rise in the east?
Just out of curiosity - how many different languages do you use regularly? And how different are they really? Because I really doubt you'd be so willing to learn every tiny, mostly useless detail of the entire language (remember, C++ spec is over 400 pages long, and that's without the standard library!) if you've had to juggle 6 or 7 of them on daily basis. And I'd love to see you recite from memory all the precedence rules governing Scala's operators - where you can make up brand new ones from any symbols you want!
Aren't programming languages supposed to make lives easier, not harder?
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Aren't programming languages supposed to make lives easier, not harder?
-
@HardwareGeek operative word: supposed.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
Aren't programming languages
supposedintended to make lives easier, not harder?FTFY. And you know what they say about intent...
-
@Tsaukpaetra aren't those synonymous? Serious question.
-
@Gąska said in When the reviewer doesn't understand my Javascript it's his fault:
@Tsaukpaetra aren't those synonymous? Serious question.
They're very similar, but I don't think they're direct synonyms. But I'm not a linguist.