Or requires a timestamp with zone offset, but ignores the zone offset, so you have to send the timestamp itself with a zone offset of zero relative to the systems timezone, but can’t just omit the zone offset, because it’s required.
When the API returns UTC, but mandates that you give it an offset which it will add or subtract from the UTC time, while still adding the Z at the end.
I’m appalled that classes representing visual styles are still a thing. I thought everyone already figured that it was a bad idea back in bootstrap days. But then I recently had an opportunity to work on project that uses Vuetify and saw quite long poems about flexboxes in class names…
Well, there’s not exactly a class training you have to take before writing CSS, so everyone starting out with it gets to make all those same mistakes for themselves before they know how to use classes sensibly. I myself am some backend guy, who has to write CSS far too often.
It certainly also does not help that various CSS frameworks out there do exactly that…
It certainly also does not help that various CSS frameworks out there do exactly that…
Bootstrap (as of v5) being one of them. div class="d-flex gap-2 my-3 align-items-center flex-nowrap justify-content-between
I was annoyed at this at first, but I’ve since noticed that I write hardly any CSS any more, because most rules really are “just add some space, vertically align, be red”.
I had to look up what these do, so they might not be precisely correct translations, but hopefully, you get the idea. It’s mostly like using inline styles, and like not using classes.
In some scenarios, these frameworks might simplify certain things, like how my applies two CSS rules. And they reduce the visual clutter of inline styling somewhat.
But overall, it feels like people are dissatisfied with semantic classes, but don’t want to lead the discussion for using inline styles, so they grab these CSS frameworks to pretend that they’re not using inline styles.
It is fundamentally a difficult discussion to lead, because inline styles feel great, while you’re writing them. They’re less great for maintenance.
But semantic classes definitely have long-term problems, too.
“Figured it was a bad idea” actually means that some people were against it because they believed semantic class names were the solution, I was one of them. This was purely ideological, it wasn’t based on practical experience because everyone knew maintaining CSS was a bitch. Heck, starting a new project with the semantic CSS approach was a bitch because if you didn’t spend 2 months planning ahead you’d end up with soup that was turning sour before it ever left the stove.
Bootstrap and the likes were born out of the issues the semantic approach had, and their success and numbers are a testimony to how real the issue was, and I say this as someone who never used and despised bootstrap. Maintaining semantic CSS was hard, starting was hard, the only thing that approach had going for it was this idea that you were using CSS the way it was meant to be used, it had nothing to do with the practicality. Sure, your html becomes prettier to look at, but what good is that when your clean html is just hiding the monstrosity of your CSS file? Your clean html was supposed to be beneficial to the developer experience, but it never succeeded in doing that.
Either you understand that the consensus is that naming things is hard and you just want to elevate yourself above everyone else by arguing against it, or you’re unaware that it is the consensus, in which case your opinion doesn’t really matter because you most likely underestimate the issue.
It’s such a truism that I’d suggest googling "naming things is hard*.
There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton
At work we let Typescript and descriptive naming document our code. Only when something is a workaround or otherwise weird will we add comments. So far it has worked great for us.
this is why i very varely comment with descriptive comments. If you’re reading my code and don’t understand what it is, even with how shit it is, you have no business reading whatever fucking crackpot shit im writing.
Doesn’t matter. Even if it’s your code, you might revisit something you made months or a year after doing it and having comments will speed up your work. It’s a very basic good practice.
i do have comments, for some things, but there are a lot of “commenting” standards that are just shit. I find i don’t care what the actual piece of code is doing, i care more about it’s place in the rest of the code, and i’d much rather have “anti comments” instead.
Good code is self-explanatory. You should only comment your code if it does something unexpectedly complicated.
That being said, it’s always a good idea to write a manual, about how to use the code. Don’t document how it works, because those who can code will understand it anyways, and those who can’t, have no need to understand it.
Yes. This 1000x. I hate it at work when I come across code that was written 3 years ago that has literally no traces of why it’s there and a quick summary of what it does. Especially because that code is always the most abbreviated spaghetti you’ve ever seen. People should stop thinking (their) code documents itself because 99.999% of programmers cannot do it right.
I really like the Google way of coding: assume the person reading the code is the most 1337 programmer ever, BUT that this person knows absolutely nothing about the project
This is something a lot of people don’t seem to understand. Even if code is self-explanatory, I want to know why it was designed that way.
I’ve fixed bugs where the fix was only a one line change, but it was extremely difficult to figure out, so I left a 10ish line comment above it explaining why it has to be done that way.
Hard disagree. It’s a lot easier and faster to understand a function that is prefaced with a small line of text explaining what it does rather than trying to figure it out yourself.
It’s not about whether you can understand the code or not, it’s about efficiency and clarity.
<span style="color:#323232;">// Calculates Personal Income Tax by formula from section 1.2.3 of tax code. Other taxes like VAT are not calculated.
</span><span style="color:#323232;">function calculateTax() { }
</span>
I’m a new developer. Is that referring to page 123 of the in-house documentation? Version 12.3 of the code? I have no clue.
You’d have to call it something like calculatePersonalIncomeTaxPerTaxCodeSection1_2_3, but I get exhausted just looking at that. There comes a point where the cognitive work of reading crazy long camel case names is more trouble than it’s worth.
An explanation of what specification a function was written to implement is a perfectly appropriate comment. Could be improved by a direct link where possible. But it’s worth noting what that comment isn’t doing - specifying any implementation details. For that, I really can just read the code.
If done right, the “what it does” is in the method name. If your method is too complicated to summarize in its name, chances are good you should split it up or extract parts of it.
Yeah, just 15 seconds and jot down a comment. Whenever I’m even hesitant, I just leave a comment. Doesn’t hurt anything and it can always be removed if not needed
Easier to remove later rather than add it after the fact
This is true, but it’s easier and faster to parse plain English and so if I don’t adequately comment my code the first time. I will be commenting it when I have to return to it for whatever reason. Honestly the second round of commenting is more verbose and clearer than the function x does y style of comments I tend to make when coding the first time
Asinine business logic can still make some things very hard to read and digest no matter how well-planned and well-written it is (particularly if it is rushed by the business meaning that engineers don't have time to do it well). As such, there are places where code can't/won't be self-documenting to a useful degree.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.