x += 1; // Increases x by one
Bill is a pro grammer
Submitted 11 months ago by CowsLookLikeMaps@sh.itjust.works to programmer_humor@programming.dev
https://sh.itjust.works/pictrs/image/3287150f-9eb1-4767-839c-c9da99ecfe19.jpeg
Comments
magic_lobster_party@kbin.social 11 months ago
towerful@programming.dev 11 months ago
// increase the dynamically allocated memory space of a byte integer represented by the symbol “x” by the integer 1 and terminate the instruction
Anders429@programming.dev 11 months ago
Why the heck does it need to be dynamically allocated? Just put that puppy on the stack.
autokludge@programming.dev 11 months ago
…Years later
x += config.increment; // Increases x by oneZILtoid1991@kbin.social 11 months ago
x++; // Move X position forward by oneThere, I made that kind of comment more useful!
LostXOR@kbin.social 11 months ago
x++; // Set x to the incrementation of the value of x
Much better.Jakylla@sh.itjust.works 11 months ago
// Move to the right
ILikeBoobies@lemmy.ca 11 months ago
Bill is not replaceable
thtroyer@programming.dev 11 months ago
Bill is a liability.
docAvid@midwest.social 11 months ago
But an irreplaceable liability.
javi@programming.dev 11 months ago
hello
docAvid@midwest.social 11 months ago
But an irreplaceable liability.
Static_Rocket@lemmy.world 11 months ago
I strive to replace bill. I only work on undocumented code from 3rd parties.
Sweetpeaches69@lemmy.world 11 months ago
I salute you.
MonkderZweite@feddit.ch 11 months ago
Bill does not work with other people.
MystikIncarnate@lemmy.ca 11 months ago
More like, other people won’t work with Bill.
Smoogs@lemmy.world 11 months ago
“Nobody wants to work anymore” -bad manager mating call.
Kolanaki@yiffit.net 11 months ago
“I’ll just be extremely precise with my variable names. Then everyone will know exactly what everything does!”
nexussapphire@lemm.ee 11 months ago
I’ll be that person who makes an catch block for something as simple as double n = 2+5.
EnderMB@lemmy.world 11 months ago
Comments don’t describe the code. They describe the decision to use this business logic.
If you stick to good engineering practices, like small methods/functions, decoupling, and having testable code, you don’t often need many comments to show what your code does. I always recommend a method signature, though, because you can save a few seconds by just saying that a block of code does, rather than me needing to read exactly how you turned one dict into another dict…
MrSqueezles@lemm.ee 11 months ago
I agree for inline code comments, like, “# Save the sprocket”, right above the line that saves the sprocket. Does this include documentation? Because when I see a
prepareForSavefunction that references 10 other functions and I just want to know, “Is this mutating and how is it preparing for save and when should I call it?”, having the author spend 15 seconds telling me is less time consuming than me spending 5 minutes reading code to find out. Anyone who has read API docs has benefited from documentation.EnderMB@lemmy.world 11 months ago
No, commenting a function should be commonplace, if not only so that your IDE/editor can use the documentation when the signature is found elsewhere in your code.
Within a function, though, basically means that something gnarly is happening that wouldn’t be obvious, or that the function is doing more than it (probably) should.
dylanTheDeveloper@lemmy.world 11 months ago
Bill should have his own special branch, Bills Branch
reverendsteveii@lemm.ee 11 months ago
//Get CustomerInfo from CustomerRepository by Customer ID or else throw an CustomerNotFoundException public CustomerInfo getById(String customerId) { return customerRepository.getById(customerId).orElseThrow(new CustomerNotFoundException()); }This is the kind of pointless comment I see in my codebase all the time. Best I can tell, a couple of my coworkers like to plan out their code using comments, then backfill in the actual executable code. That’s fine, but they leave the comments in when they add no value.
public static LocalDate parseEndDateFromString(String dateString) { try { String[] split = dateString.split(“-”); //In order to get the last day of the desired month, we go to the first day of the next month, account for rollover, then subtract one day int month = Integer.parseInt(split[0]) == 12 ? 1 : Integer.parseInt(split[0]) + 1; return LocalDate.of(Integer.parseInt(split[1]), month, 1).minusDays(1); } catch (Exception e) { throw new RuntimeException(“Invalid date format - must be MM-YYYY”); } }Stuff like this, otoh, is where comments are useful. The required format is obvious from the error message, the param and return from the method signature, the only part that requires a comment is the fiddly logic of accounting for the edge case where month == 12 and the rationale behind how we determine the last day of the month.
spudwart@spudwart.com 11 months ago
Make it deceptively easy to read.
It appears easy to read in a review of the code, but upon any further glance, to actually keep it up, the only one who can understand it is you.
RGB3x3@lemmy.world 11 months ago
That’s just job security
Haus@kbin.social 11 months ago
This is what I call a 'pro grammar move.'
Smoogs@lemmy.world 11 months ago
Wow the comments here sounds like you’re all a bunch of antisocial nightmares to deal with in rL.
frezik@midwest.social 11 months ago
That would be the type of people attracted to programming, yes.
nailbar@sopuli.xyz 11 months ago
I consider myself social. I’m a programmer because I love making things, and because I’m lazy, and I hate doing repetitive tasks.
DontTreadOnBigfoot@lemmy.world 11 months ago
Welcome to Lemmy
pewpew@feddit.it 11 months ago
Code looks better without comments
BaardFigur@lemmy.world 11 months ago
Comment smart, don’t comment every line like this
int i = 5; // Assigns the value 5 into the varible i.
Maalus@lemmy.world 11 months ago
Comment only in extraordinary situations, when something you read can confuse someone. And by that I mean the business logic, not that you used a method that’s confusing to people since they only know the basics of the language.
stebo02@sopuli.xyz 11 months ago
I usually comment on whole groups of lines of code, so the goal of each part of the code is clear
RagingRobot@lemmy.world 11 months ago
I would disagree. I love to use comments to format my code and separate the sections. I think it’s so beautiful. Also I love when libraries have ASCII art in the comments at the top of the main file lol. It makes the code more fun in my opinion.
I went to college with a guy who would tear the code as art when presenting projects. His code was always beautiful. Not super functional but always beautiful. It always stuck with me. I want my code to always be functional and beautiful. Easy to read and a pleasure to work with. That’s my goal at least. Comments help with that.
Also it depends on what the code is for haha
wit@lemmy.world 11 months ago
Code should be self documenting.
JohnDClay@sh.itjust.works 11 months ago
But you should also comment it, things obvious to you aren’t obvious to even future you.
gornius@lemmy.world 11 months ago
General rule of thumb: Comments say why is it here, not what it does. Code itself should describe what it does.
Sylvartas@lemmy.world 11 months ago
But then you write code in the real world and find out that you have to write some ass backwards code every other day because of deadlines, backwards compatibility or whatever, and suddenly you realize that despite your best efforts, code cannot always be self documenting.
Source: me.
executivechimp@discuss.tchncs.de 11 months ago
should
Sylvartas@lemmy.world 11 months ago
In a vacuum, sure. On a real project of substantial size with more than one programmer, I’m afraid it’s a “cannot”
youCanCallMeDragon@lemmy.world 11 months ago
I wonder if chat GPT can add comments
charliespider@lemmy.world 11 months ago
Chat GPT is great at writing comments. Usually writes better comments than I do.
Landless2029@lemmy.world 11 months ago
I second github copilot
Landless2029@lemmy.world 11 months ago
Try github copilot I’ve canceled my chatgpt for it.
Now I start scripting by doing all my comments. Essentially make a outline like I’m writing a paper.
Copilot suggests the code that matches my comments.
I script legit 3x~4x faster now with full comments. It’s amazing.
onlinepersona@programming.dev 11 months ago
Image
philm@programming.dev 11 months ago
Yeah, but unironic…
If your code needs comments, it’s either because it’s unnecessarily complex/convoluted, or because there’s more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don’t age well IME, and when people are “forced” to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.
Good video I really recommend: www.youtube.com/watch?v=Bf7vDBBOBUA
Pickle_Jr@lemmy.dbzer0.com 11 months ago
Yeah, another way I’ve heard it phrased is comments are for explaining why you did things a certain way, not for explaining what it’s doing.
floofloof@lemmy.ca 11 months ago
If you’re working with others, even simple code benefits from comments explaining what it’s intended to do. Sure you can read code and get a good idea of what it seems to do, but having a quick statement from the author enables you to work faster. And if you find a mismatch between the comment and the code, it’s a smell that could mean a bug.
And for methods and functions it’s particularly helpful to have a description at the top. Many IDEs will pop this up when you’re using the method, so you can quickly confirm that it’s appropriate for your needs and get your arguments in the right order.
potustheplant@feddit.nl 11 months ago
That’s like saying a book’s synopsis shouldn’t exist because you can just read the whole book. Sometimes comments can save you a lot of time and point you in the right direction.
DaleGribble88@programming.dev 11 months ago
I have such a love-hate relationship with that video. On the whole, I think that video is bad and should be taken down. The creator is arguing against a very specific type of commenting but is harassing comments in all forms. It even addresses as such with a 20 second blurb 2/3 of the way into video distinguishing between “documentation comments” - but doesn’t really provide any examples of what a good documentation comment is. Just a blurred mention of “something something Java Doc something something better code leads to better documentation” but doesn’t elaborate why. It’s a very devious problem in that I don’t feel like any particular claim in the video is wrong, but taken within the context of the average viewer, (I teach intro. comp. sci courses and students LOVE to send this video and similar articles to me for why they shouldn’t have to comment their spaghettified monstrosities), and the inconsistent use of comments vs. code duplication vs. documentation, the video seems problematic if not half-baked. In fairness, it is great advice for someone who has been working in the industry for 15 years and still applies for junior positions within the same company - but I can’t imagine that was the target audience for this video. In my experience, anyone who has been programming on a large-ish project for more than 6 months can reach the same conclusions as this video.
BeigeAgenda@lemmy.ca 11 months ago
Sounds very theoretical, my experience working on some 40 year old software full of business logic, where customer A got some feature but customer B needs it to work slightly different. Aka something approaching spaghetti.
Regarding old comments I have several times used ~15 year old comments by the original author, close to the actual code to piece together the use of that code, and if I can add my fix there.
In this setting You write comments for yourself, when you in two years need to fix a bug in the new code caused by your old code. And for the next developer that will look at your code decades after you left the company.
Sometimes you, against good practice, comment out a section, with a note why, because you know this will have to be re-enabled in a few months.
Report from the frontlines…
astraeus@programming.dev 11 months ago
This mindset is good, but unfortunately enforces bad programmers to leave their undocumented code in critical places where someone eventually has to figure out what the hell they were doing or refactor the whole damn thing because they got promoted to middle-management and can’t be bothered to remember why they even wrote it.
magic_lobster_party@kbin.social 11 months ago
I’ve seen code that look like this:
int delay = 15 * 60; // 10 minutesEven if the comment was on the same line someone forgot to update it.
Better solution is to write (in C#):
TimeSpan delay = TimeSpan.FromMinutes(15)Much more obvious what the code actually means.
Awkwardparticle@programming.dev 11 months ago
One day you will inherit a code base so bad that you’ll end up commenting old code just to make sense of it for yourself because nobody in the company has touched in a couple years and the last people that did no longer work there. It will be dangerously coupled, if you make the right change somewhere it will break everything else. It will be true spaghetti code where you spend 30 min just following a code path to figure out what and why an input into a function needs to be what it is to able to come out of another function in an exact format for anything to work.
Your so called comment standards and principals are fine if you are building something from the ground up, but the other 95% of the time, you do what you gotta do because your were blessed with a turd that is impossible to polish.
Vilian@lemmy.ca 11 months ago
and if you need an unnecessarily complex ode for performance sake?
CowsLookLikeMaps@sh.itjust.works 11 months ago
Or you’re stuck within the confines of a horrible legacy system which the business will not allow you the time to refactor/rewrite but still want your code to be somewhat readable.
But in general, I agree with your argument. When writing from scratch or improving reasonably well designed code, often documentation could be replaced by breaking it up into another function or naming variable better. It’s a bit of a code smell for violating the SRP.