And was it always wrong or has it become wrong due to a change in the ecosystem?
For further actions, you may consider blocking this person and/or reporting abuse
And was it always wrong or has it become wrong due to a change in the ecosystem?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (84)
That you always have to put extremly verbose and meaningful variable names. In general yes!
But it depends on the scope of the variable.
There is nothing wrong to use variable names like 'el' or 'num' in lambda functions like e.g. foreach(el => ...)
It all depends on your language's conventions. I've often seen these be standard, many coming from mathematics itself:
i,j: indices, loop control variables (no lifetime beyond context).x,y,n: temporary variables in algorithm (no lifetime beyond algorithm)n,num: temporary "number", such as an accumulator or the current value when iterating over numbers (no lifetime beyond context).v,val: temporary value, usually from iteration (no lifetime beyond context)x,y,z: coordinates (meaning from context).len: lengthiter,it: iteratorBeyond that, you should probably write real names.
That depends on what the loop, temp var (etc.) does. Sometimes having a meaningless name like that is perfectly fine, something you need something more descriptive as it may help read what's being done more easily (I just coded a case like that this morning).
Why not? I'd rather see a meaningful variable name that describes its purpose rather than something generic that I have to figure out on my own.
That two similar-looking pieces of code must alway be abstracted out, because DRY.
I usually do feel like I want to DRY things up once I hit 3 or 4 times though, at least if the block of code is at least like 10 lines long
I think a useful heuristic is 3. If you see the same thing implemented 3 times, it's worth considering, at least, if it's time to refactor and DRY it up
The mistake here: people assume they need to DRY up repeated code. This is wrong. They need to DRY up repeated knowledge in the software.
Seems profound here and like this could be highly useful. Could you maybe expand on how to identify the difference between knowledge and repeated code?
That ids and classes are CSS features. They're HTML features, for describing the semantics of the page content. It wasn't always wrong. Their purpose got subverted when web page construction got split between content authors and designers, and designers found that CSS provided no good hooks to hang their styles off.
Can't they be both? CSS is pretty tightly coupled with HTML; is it meaningful/useful to make a distinction about which language they "belong" to? For that matter, what use are classes strictly within HTML, with no reference to CSS or JS? While ids are used by ARIA attributes and in some special cases like
<label for="id-of-input-field">, afaik classes don't serve any such purpose. But I love to learn, so am I wrong?A few years ago I went through the HTML5 (then draft) spec and counted the uses of the id attribute. I found 11 (actually I found 12, but 1 was subsequently removed), only one of which was for use in coupling DOM elements to CSS. As well as Labels and Aria, there's coupling form controls to their forms, fragment identifiers in URLs, connecting table cells to their headers, and so on.
Classes have indeed fewer uses. But even so, besides CSS coupling, they are used in JavaScript via
GetElementsByClassName()andquerySelectorAll(). They're also used in microformats.You've probably noticed that I refer to coupling to CSS. That's because I dispute the idea that HTML and CSS are tightly coupled. They're coupled entirely through Selectors (bar some special case behaviours in the overflow and background properties). But most relevant here is the use of id and classes in Selectors. And this is the point - if you look at recent Selectors specs, e.g. the Level 4 spec, they're not called "CSS Selectors", they're just "Selectors".
Selectors are designed to be the binding between DOM elements (for both HTML and XML documents) and other languages including both JavaScript and CSS. The Selectors spec even includes the snapshot profile which is specifically for non CSS uses. Only that non-CSS use contains the
:has()pseudo-class.So it is my contention that HTML and CSS declaration blocks are separate. Selectors provides the binding between the semantics world of HTML and the styling world of CSS, helping enforce the separation of concerns that inspired the invention of CSS, replacing the styling elements and attributes that were creeping into HTML. Selectors use id and classes, but so do other aspects of the web ecosystem. CSS uses Selectors but so does JavaScript.
I agree with the above point, If I'm running
users.each do |u|in Ruby, I think thatuis pretty communicative, even if it's shorthand.But I'd personally avoid
var1or meaninglessx,y,z, even if it's just your own thing. That one second to come up with a somewhat meaningful variable still seems useful even for your own train of thought.Java Slogan: Write once, run anywhere.
I think it was (that's from my memory way back in 1994 or so):
"Write once, run everywhere"
Which quickly turned into:
"Write once, test everywhere" because of all the different VM implementations. That was back in the Java 1.0.1 days.
:) ...
That $mylanguage is better than $yourlanguage.
Programming languages are tools that are meant for specific purposes. One language might be suited better than another in this scenario, but maybe not in another.
That's why I like to say "this is my personal favorite language" because I'm not trying to make claims about it being objectively better, but I enjoy working in it and with the scenarios it's best suited for.
PHP BAD
Thank you!
That an academic degree in computer science is needed for software developers. Worst: that said degree makes one a better developer (or a developer at all, for that matter).
Most CS degrees aren't solely focused on software development. They are rooted in theory, data structures & algorithms (and the mathematics beneath them), and whatever electives are offered by the institution (today a lot of them are AI/Data Science intro courses). In my program, we have two classes where we build big projects, and in the end, there's a capstone project, but I have no idea how developers function in the wild. I feel like a lot of CS students live under a rock (at least I do :D )
Academia is a long lost cause for producing really only two things - academics or good worker bees. Only life can produce educated thoughtful and well-informed people. As one of the comments mentioned Ai and data science, that's what industry wants not what you want. If you're going to waste money on a degree, waste a lot of money and take the classes that you want, then force yourself to do the minimum requirements for the degree but only because it's handy to help you get a job not because it has anything to do with education.
"It's industry-standard". This is often used to try and end debate, but the "industry-standard" for most things seems to have a shorter and shorter lifecycle as new and emergent technologies make them obsolete.
If it's a phrase you have to use to explain a solution, then you're doing it wrong. Even if it's an "industry standard" for a good reason, the underlying reason for it matters more than the fact it's an "industry standard".
Does "we tried this already" count as conventional wisdom? 😝
This one hurts 😂 😭
Especially when there's no documentation to review what was "tried" or what the results were.
You get me!
Yes, it's a problem because, what they don't say is when they tried it. This is the same fallacy as 'we've always done it this way'
This is probably a hot take, but when people say "choose the best tool for the job". There are so many tools and libraries out there that you aren't gaining much by sifting through all of them to find "the best" one out there.
More often then not, I see engineers get into "analysis paralysis" and end up taking a long time to make a decision when several of those options would be more than suitable.
Sure there are cases where the options aren't so plentiful, but this is definitely becoming the exception rather than the rule.
I think what's often meant is "don't listen to fad-based admonishments to use X or avoid Y." Of course, that's quite lost in "choose the best tool".
I tend to adjust that aphorism myself:
Use what works, popular opinion be darned.
I see this very frequently in common everyday engineering decisions. A recent one I saw was "Which config management tool should we use between Salt, Puppet, and Chef?". Others I see, "which static code analyzer...", "which framework...", "which data store...", "which log aggregation tool...", "which apm...".
There's definitely an element of "avoid the fad" in the conversation, but where I mostly see people get stuck is deciding between the more time-tested and stable options. Each option might be valid, but they get stuck on "find the best".
At that point, I like to ask them "Well, which one do(es) you(r team) know best?"
If that fails, and if the basic feature lists of each provides no insight, then flip a coin.
Sorry to reply twice, but I have to wonder...
How many people, by saying "use the best tools for the job", are actually only saying "use my favorite tools for the job"? (After all, "my favorite tools are always the best.")
I think this happens a lot and it definitely hurts the conversation.
I like your comment about flipping a coin :) It bothers some folks since it doesn't seem like a rigorous argument, but at that point you don't need one.