Still false, thanks to compiler optimizations. Remember that integer overflow is UB. (unless you’re using unsigned int or a programming language which strictly defines integer overflow, possibly as an error)
<span style="color:#323232;">for (int y = MIN_INT; y <= MAX_INT; y++) {
</span><span style="color:#323232;"> if (y == x + 1) {
</span><span style="color:#323232;"> x = y;
</span><span style="color:#323232;"> }
</span><span style="color:#323232;">}
</span>
(Not sure there’s a way to prevent Lemmy from escaping my left angle bracket. I definitely didn’t type ampersand-el-tee. You’ll just have to squint and pretend. I’m using the default lemmy-ui frontend.)
The backticks worked in the preview, and showed up correctly to start, but there must be a bug in the lemmy ui, since now it’s double-escaped. No idea /shrug
It will not “overflow”. Signed integer overflow is undefined behavior. The compiler could remove the whole loop or do anything else imaginable (or not).
Languages with dynamic typing and implicit large-integer types, such as Python and Ruby, generally just convert to that large-integer type.
I figured Java would probably define the behavior in the JVM, but based on a quick web search it sounds like it probably doesn’t by default, but does provide library methods to add or subtract safely.
Rust guarantees a panic by default, but provides library methods for wrapping, saturating, and unchecked (i.e. unsafely opting back in to undefined behavior).
It’s amazing how much work goes into cleaning up code before you feel comfortable posting it to a mailing list that you would never even bother doing for internal-only stuff.
I’m fairly certain that last one is UB in C. The result of an assignment operator is not an lvalue, and even if it were it’s UB (at least in C99) to modify the stored value of an object more than once between two adjacent sequence points. It might work in C++, though.
me when first starting out at a job commenting everything I can
VS
me a couple years in completely lost because I never updated the comments and now none of them make any sense whatsoever
Commenting well is a highly advanced skill. I generally prefer no comments on code since it’s less likely to confuse people and I’ll merrily purge auto-doc comments and anything like
I write a lot of fairly simple scripts in Bash and PowerShell that should be easily understood by anybody else with moderate experience in the language, but I leave a lot of obvious comments because my coworkers don’t write any code and are extremely skittish about my automations. I add them basically to quell their fears.
These are scripts that manage stuff on a few hundred user endpoints and a few servers. They were doing basically everything manually until I got here, and the only way I could get them on board with my slow introduction of automation is to let them see it. I have to ensure things don’t get too long, complex, or hard to explain, or they start getting nervous.
Yeah. Most of the time I use comments in my algorithms, as they often use some weird optimized black magic which are difficult to understand without comments.
There are some cases though where the code is just complicated for reasons outside of your control, in which case “what” comments are good - but they should never be taken at face value, but only used as a first step in understanding the code. There’s a significant risk of the code not actually doing what the comment says.
In my experience refactoring lots and lots of crappy code left by devs long gone, a dev who can write useful comments is by and large a dev who can write code clean and simple enough not to need them. If the code doesn’t have informative names and clear separation of concern, chances are a comment won’t help because the dev didn’t really know what they did that worked in the first place.
Generally, yes. However I have been known to document exactly why I’m doing something incredibly stupid - because it’s required but a stupid third party library which, despite being awful, is still better than implementing it myself as a refactor.
I’d rather teach people to comment well through my reviews. Much easier to understand two lines of well written function description in English than 20 lines of code.
Unfortunately if you let Junior play in legacy code once, it'll learn some nasty habits and make more of it from scratch, usually when you're trying to sleep.
If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).
Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.
If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.
Nah, they’re the one who’s contributing most to the project. Mostly because their code is so garbage no one else can work with it. But that’s not a thing the managers take into account.
This shit happened the other week for me. Senior dev pushed the shittiest JS code without testing the day of a production install and it caused us to have to roll back the install after it very predictably caused a bunch of crashes for pages on our public site. Worst part is, the entirety of what he wrote could’ve been implemented as a CSS media query
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.