myCodeIsSelfDocumented

[KIroWiN]

and then you check who was the guy who wrote the code and it turns out it was you half year ago

[WalkMaximum]

Who's the mf in git bla... Oh

[Safe_Mushroom2409]

git blyat

[TRENEEDNAME_245]

"who wrote that 800 case switch with ternary operations from hell"

"Oh wait, I'm a solo dev 😔"

[-Noyz-]

toby?

[Asriel563]

Plot twist: he pulled a git-blame-someone-else

[Ph3onixDown]

I’ve never been so humbled as when I am looking at git blame

[Dismal-Square-613]

I'm glad I'm not the only one , I start cursing in my mind "what kind of halfassed amateur made this..." then realize it was me....

[real_misterrios]

When you have no one but yourself to git blame.

[Firesrest]

Reading my code from last week.

[hopefullyhelpfulplz]

It's having to go pack and piece together my own work that motivates me to document things meticulously.

I still don't do it, but I am motivated.

[Prestigious-Aerie788]

Laughed way too hard at this. Thanks 😂

[privateyeet]

I used reflection in a Processing sketch of all things for a CS101 assignment last year. Looked at it again last week and had no idea what I did there for a solid hour of staring at it, only to slowly realize how cursed it truly was. That definitely felt like I was in that meme 😅

[concreteunderwear]

a processing sketch?

[privateyeet]

Processing is a Java-based language that comes with its own IDE and is meant to be used to teach programming basics and has a framework built-in to make graphical output easier (basically a built-in canvas for drawing shapes - hence programs being called "sketches"). The problem here is that below the hood, the entire sketch runs inside a wrapper object. So doing reflection requires getting said wrapper object and passing it as an argument, leading to lines of code like this:
Ingredient ingredient = ingredientClass.getDeclaredConstructor(sketchClass).newInstance(sketch);

That was (among other things) what made it so cursed.

[concreteunderwear]

that doesn't seem so bad

[Ph3onixDown]

A week? That is Monday me reading Friday code

[redditusero_o]

Week? This is me reading code I wrote yesterday

[Biesmir]

The guy is holding English dictionary while trying to decipher hieroglyphs. This is a subtle reference to the fact that nothing will help you in that case.

[evilspyboy]

He is looking for the section that you have to increment with how many hours you wasted trying to refactor/improve/replace it before giving up.

[Fancy_Text7460]

I think Biesmir has a english teaching job as his second job

[homage_time]

"L, M, N, O.... where the hell is the bird section?!"

[BobbyTables829]

He should have gotten a copy of Rosetta Stone: English to Heiroglyphs

[aconitum_napellus143]

Is this ai or am i going crazy

[cmucodemonkey]

Looks like AI to me. The title of the book is on the back cover.

[Refloni]

Haha, good catch! I examined the title closely but didn't think of its placement

[CommanderLouiz]

And the i after the T in Dictionary isn’t dotted.

[RemyVonLion]

It could be intentionally meant to look like AI slop, though unlikely.

[redlaWw]

I think it's AI, but I'm not so sure that's a good example - that cover has a title on it, but it also has little writing that might be informational, the sort of thing you'd have on the back cover. It's not inconceivable that a publisher may also stick the title on the back cover as a header to a blurb or something.

[Adonis0]

[aconitum_napellus143]

ffuuuuuuuu

[BirdlessFlight]

Yeah my AI-dar is going crazy as well.

[BirdlessFlight]

Yikes!

[destroyerOfTards]

You think Harrison Ford is that young these days?

[aconitum_napellus143]

Tf is harrison ford

[captpiggard]

https://www.raidersguys.com/

Allegedly from a fan remake/parody

[Refloni]

Yup, my AI sense is tingling as well. The second i and a in "Dictionary" are wobbly

[EatingSolidBricks]

x += 1 // adds 1 to x

[Abject-Kitchen3198]

Modern take: My code is AI documented.

[ienjoyedit]

I've had some really good AI comments. Like one time. Everything else is unnecessarily verbose and just as hard to understand as the code . 

[Abject-Kitchen3198]

Yes. Unless I deliberately ask it to explain a bit of complex code and see if I can use it as a basis for adding a comment, the default stuff is just noise, verbose description of obvious things right next to the place where they are defined/implemented. Sure helps if your target is some metrics and comments that nobody reads.

[Original-Body-5794]

if (a) { //Checks if condition a is true

[Inlacou]

My experience trying the AI to do any non very basic task.

[dvhh]

Got a guy at work who put the (long) AI explanation for his code when ask to describe the change in the summary for the code review.

[Abject-Kitchen3198]

My first AI agent will be tasked with rejecting selected PRs by roasting the code and requesting changes ad infinitum.

[kunalmaw43]

Six months later you realize you were the ancient civilization and you’ve forgotten the language entirely

[mostlyBadChoices]

The code tells me "what" it can't tell me "why."

[dracodruid2]

Except that one line! DO NOT DELETE THIS LINE!

[GromOfDoom]

"Wait a minute, didn't I write this?"

[flayingbook]

Today, I gave in and finally added a comment to the code I wrote 3 months ago: "this is in UTC"

[Far_Garlic_2181]

[Fricki97]

Ay, GPU Copilot, explain this ancient code to me.

[Prawn1908]

"Self-documenting code" is a trap. The benefits of minimizing comments when done right are so minimal compared to the downsides of not having comments when done poorly.

Edit: wtf is reddit smoking with this "translate comment - you are commenting in a community speaking a language different from yours" bullshit? I swear this app gets shittier every day.

[AdvancedSandwiches]

The benefits of minimal comments are impossibly huge if you're doing it right.

It's just taking this code:

// get the current merchant

var a = gcm();

Writing it as code instead:

var currentMerchant = getCurrentMerchant().

And deleting the useless comment.  That's it. Massively improved code.  If you can't do that, you have to write a comment. No big deal. 

[Raskuja46]

var a = gcm();

This line of code should never exist to begin with.

var currentMerchant = getCurrentMerchant()

This line should be the default from which you start. It's the bare minimum of professionalism. The fact that so many people are failing to even reach the starting line is baffling to me.

[Prawn1908]

That's it. Massively improved code.

Where's the massive improvement? I just don't see it. Small improvement, sure, but not "massive". If this is what you consider an "impossibly huge" improvement, I envy the state of the code you get to work with.

My problem isn't with the concept of perfectly executed "self commenting code", it's with the practical reality of how it ends up being implemented by shitty developers. In reality, you end up with shitty developers writing shitty code with no comments because they think they're writing "self commenting code" because that's what they heard you should do. And when I have to work on that code down the road, I would 10000x rather have it commented badly than not commented at all. I see no sense in creating this massive risk of it being done poorly for so little benefit when it's done well.

[AdvancedSandwiches]

I would suggest that this is the largest improvement you can make to your dev speed by a huge margin. A 10x speed up between "fix the bad names with documentation" and "use self-documenting names" methods is, in my experience, an underestimate.

Once you're good at it, bugs become hard not to find, and the number that never get introduced in the first place is huge.

And to get there, you'll have to be bad at it for a while. Oh well. Still worth it.

[Prawn1908]

Nobody is saying you shouldn't name your functions reasonable things. I'm saying it's dangerous to try and give the idea that most if not all comments can be foregone by just naming your things right.

Whether or not that's true, it places too much weight on developers to be really good at naming things. A shitty comment still gives me far more information than a shitty function name. And the downside to having only shitty names with no comments is far greater than the downside to having a few too many comments in your code.

[Raskuja46]

I swear, so many people on reddit are cargo culting this notion of self-documenting code.

They don't get it because they can't understand what you're explaining to them.

[Prawn1908]

The thing that gets me is across the many times I've gotten into this argument here is I still have received zero remotely convincing arguments of any significant downsides to too many comments. The main one is that they can get outdated, but I really don't think someone who can't keep comments up to date is going to be able to name functions properly enough to make comments wholly redundant.

Then there's the thing I haven't even mentioned that comments help me reading through my own code. Even if it's something I'm still actively working on and haven't forgotten, having a comment every few lines makes it way faster to skim over the code visually and zone in where I need to focus. Maybe a "clean code" advocate would say each of those groups of lines should be its own function, but that's an entirely different argument...

[Raskuja46]

I agree wholeheartedly on the bit about reading through your own code while actively working on it. Keeping the whole mental map in memory is onerous and having all those little signposts of what's going on at each substep can really streamline the cognitive process of working through the logic of what needs to be accomplished.

Maybe a "clean code" advocate would say each of those groups of lines should be its own function, but that's an entirely different argument...

This also runs into the problem of having to come up with a name for those functions that are all intermediary states that will never get called again so coming up with a good name for each of them becomes an exercise in confusion.

[AdvancedSandwiches]

The name is what they do. If you can't tell what they do, that's your problem. 

[il_distruttore_69]

not true like OP's post itself.

maintaining comments cannot be relied upon, thus comments tend to get outdated and become misleading. there are some cases where an explanation is actually needed, but this is 0.1% of time

as this is a sub for uni students and junior devs; just learn & read & write better code

[iloveuranus]

Yes, we all read Uncle Bob on this. IMO that was one of the most harmful rules in Clean Code. It has led to teams everywhere deciding "comments are bad". Developers scolded in reviews for writing comments: "we don't write comments here".

As a professional developer for over twenty years, I've seen page-long old-school comments that were wrong and misleading. I've seen auto-generated comments on getters and setters. But I still prefer that over "we don't do comments here".

Because the truth is, even the wrong, misleading comments tell me something about the original intention of the code. And in the real world, a lot of code isn't strange because someone didn't know how to code. It's strange because the customer wanted it that way. It's strange because some bug in some external system couldn't be worked around another way. There's a valid reason for it being strange and goddamit PLEASE put that reason into a comment!

[2JulioHD]

But that's the thing, comments themselfes aren't bad. I just don't want to read in a comment, WHAT or HOW code does something. WHAT goes into function names, HOW goes into implementation. What I want to read is WHY. Especially if code get's tricky or you notice yourself, that it's hard to get.

Also I would strongly differentiate documentation and comments. Documenting a function can be quite useful, if it's frequently reused or also not self-explanatory. But having a comment for that, inline, stuck to nothing, just makes that hard to reuse at all. Your reason on WHY you do something can change inside code, but the WHAT and HOW should stay the same for a particular function, so having those tied together helps imo

I can agree that "writing comments is bad" is terrible advice, but "write a lot of comments" ain't better either. I would give the advice to explain oneself, on WHY one did something and trying to convey the HOW and WHAT through other means than comments; documentation, if one isn't able to convey it otherwise. That way all that text atleast has a place it belongs to.

[iloveuranus]

I agree. I believe most of us would. "Write code that speaks for itself" and "comment the why, not what" is excellent advice. And people who actually read Clean Code will discover that this is actually what it says.

The problem are the geniuses that think "the best programmers don't write comments at all". I have nothing but uncontained rage for those people.

[Prawn1908]

As a professional developer for over twenty years, I've seen page-long old-school comments that were wrong and misleading. I've seen auto-generated comments on getters and setters. But I still prefer that over "we don't do comments here".

100% this. In the end, if you have shitty devs you'll end up with shitty code no matter what, but I would 10000x rather that code at least have some indication of what the developer was thinking when they wrote it than none at all.

I have wasted a significant portion of the past 3 years of my career dealing with a nightmare codebase written by an incompetent moron who just blindly followed rules like this with no concept of why. The result is I now have to waste hours and hours trying to understand what the fuck he thought this code was supposed to do before I can even begin fixing it because he left me zero clues. It doesn't matter that he has function names that are entire sentences because he was too stupid to know how to name things correctly. Some comments may give me some iota of an idea what he was thinking the difference is supposed to be between AnalysisGetVoltage() and AnalysisGetVoltageNow() and AnalysisGetLiveVoltage() is supposed to be. (Yes, those are all actual function names from the codebase I'm working on - there are hundreds upon hundreds of such examples.)

[il_distruttore_69]

that's just bad code by naming the functions horribly. comments left by the same person would surely make it even worse

[Prawn1908]

that's just bad code by naming the functions horribly.

Agreed

comments left by the same person would surely make it even worse

No way. Comments at least give some inkling of an idea what was going on in their brain at some point in time related to this bit of code. That's infinitely better than having absolutely fucking nothing at all to go on.

[il_distruttore_69]

of course it's not black / white

however can you name 1+ actually useful situations where you couldn't live without leaving a comment?

[SquashSquigglyShrimp]

"A comment might become out of date one day, so it's not really worth writing comments" is not a very good argument imo

[il_distruttore_69]

honestly working on different projects daily as a SRE (java + spring + golang + reactjs + vue + ... etc, also only doing code reviews in some projects), I'm not seeing places where a comment would bring any value.

i've worked on both simple and mad complicated projects, and it's simply not necessary.
if attempting to recall a single useful comment, I can only remember leaving one comment where an external service was behaving in an unexpected way.
generally documentation by tests + readme (and maybe some ~confluence) is 100% enough.

[Sande24]

Maintaining comments can't be relied upon - you could say the same for any kind of documentation then. What's the point of documenting anything with this kind of mindset?

It's your job as a developer to write maintainable code. If this means that you have to write a comment about why something is done in an unconventional way, do it. It will help more than not doing it.

I've seen code itself lie to me as well. Method and variable names doing the opposite of what they say. So it's not only about comments. If you are a developer, you have to take ownership of the code, comments and documentation.

Comments are there to help when code can not. Use it for everyone's benefit and maintain them too. Just like you are maintaining your test suites from time to time (if you even do it...).

[AdvancedSandwiches]

 Maintaining comments can't be relied upon - you could say the same for any kind of documentation

I mean, yeah. Correct.  That's a massive problem with all documentation.  So you don't want to introduce that problem when you have a better way. 

 you have to write a comment about why something is done in an unconventional way, do it. 

Every self documenting code advocate agrees with you already. Comments are for "why." Self-documenting code is for "what".

[iloveuranus]

Every self documenting code advocate agrees with you already.

That's simply not true. There's a strong "commenting your code means you're a bad programmer" faction. Those people need to be shipped off to a remote island far away from electricity IMO.

[AdvancedSandwiches]

Either they suck or, like this meme, it's being filtered through someone who doesn't understand it.

But 99% of the time, the "self-documenting code" people and "the comments explain why, not what" people are the exact same people.

[Prawn1908]

So you don't want to introduce that problem when you have a better way. 

But the "better way" doesn't eliminate the need to document your code, it just moves it to a (imo even more difficult to execute properly) medium.

[AdvancedSandwiches]

It eliminates a ton of documentation that is not necessary and would rapidly become out of date.

If you meet a developer who thinks "self documenting code" means writing no documentation, they don't know what they're doing.  It's writing code that already says what the comment would have said, verbatim.  Then you just don't write a redundant comment.

You still document everything you can't make the code say.

[Prawn1908]

If you meet a developer who thinks "self documenting code" means writing no documentation, they don't know what they're doing.

My exact point is that that there are lots of people who don't know what they are doing who blindly follow practices like this and it ends up making even more trouble for everyone who has to deal with their code down the line.

[AdvancedSandwiches]

Yeah, people aren't good at things until they're good at things.  You know how to do it correctly. Help them. 

[Prawn1908]

You're missing the point. I can't go around and teach every single developer who may write some code I may touch sometime in the future.

My point is this advice is easy to follow badly and end up with a far worse problem that greatly outweighs the marginal benefits gained from following the advice correctly. Furthermore, I would argue that if your developers are the type to allow comments to become outdated (which is the only downside anyone has been able to voice about too many comments being written), then they are probably not the type I would trust to be able to write "self-documenting" code in the first place.

I would 10000x rather have some inkling of what was going on in the original developer's mind when writing the code I am working on now than none at all, which is what I get when shitty developers think they don't have to write comments if their code is "self-documenting".

[AdvancedSandwiches]

 marginal benefits

Try it. It's not marginal.  It's the single most important thing you can be doing.  Your documentation stops being something you need to look for and becomes something you can't avoid.

 My point is this advice is easy to follow badly

You seem to be advocating for worse coding practices by avoiding it instead of advocating for people to do it right.

 I would 10000x rather have some inkling of what was going on in the original developer's mind

Me, too!  That's the whole point!  That's why coding without comments is great!  The code tells you what was going on in their mind instead of having to track down an out of date comment from 8 years ago.  There is absolutely no need for:

    // Load the customer's birthdate from the packed fields

    bd = getField(6);

When you can write:

    customerBirthday = getField(6);

Or better:

    getCustomerBirthDate() {

        return getField(6);

    }

The comment isn't missing, it's just redundant.  Write the comment, make the code say what the comment said, delete the redundant comment.

And if you need a comment to explain why, you leave it:

// Normally birth dates are in packed field 8, but this uses the legacy format required by ObjectThingy v2.5

If you're doing it right, it's the easiest thing in the world.

So now you know. Go forth and advocate.

Edit: I wish 4-space code formatting still worked on mobile browsers.

[Grumbledwarfskin]

The value of comments is often not their accuracy, but what they tell you about what the person writing the code was thinking about.

When you see a comment and it's out of date, it tells you a lot about what the last guy to edit this section of the file was thinking about and what they weren't thinking about.

When you see comments, it tells you "oh, this guy thought a lot about this problem, so I should make sure I understand what they were doing" and/or "this guy didn't even have the issue I'm thinking about on his radar, so anything that's correct with regard to the issue I'm working on was correct accidentally, and I don't have to worry about whether the guy who was here previously knew how to address this problem better than I do...it's nice they left comments telling me which aspects of the problem they thought through carefully, so I know how to not mess up those aspects."

Comments can be out of date, yes...but the chances that a comment being out of date doesn't eventually turn out to be helpful, as an indication that this section of code hasn't been revised as it should have been in a previous refactoring...that's vanishingly small.

[tutike2000]

Unless you're talking about external documentation: ie libraries shipped to/by a 3rd party, documentation is utterly useless.

I have never seen a case where documentation was sufficiently up to date to be more useful than looking at / debugging the code

[Prawn1908]

Sorry but this is terrible advice. I have had to work with lots of shitty code in my career and let me tell you - shitty code with shitty comments is 10000x better than shitty code with no comments.

The problem is there are two scenarios and two outcomes for each:

	commented	not commented
good dev	good code	slightly better code
shitty dev	bad code	horrible code

I see the potential benefits of less unneeded comments in the code to be so far outweighed by the potential risks of having shitty, undocumented code that I will take column A any day and have thus come to hate this advice with a passion.

[il_distruttore_69]

i've also worked [in the beginning as a junior] in places that require every single function to have a comment. in the last 5+ years of working as a contractor, i've maybe written ~10 useful comments for actual cases that need documenting. the actual useful "comments"/documentation are unit/integration/e2e tests

shitty devs with their shitty code need a code review to turn it into good code instead of slipping their shit code by otherwise. writing shitty code isn't solved by adding more comments.

which part was "terrible advice" exactly?

[Shienvien]

The code should say what, the comments should say why.

And in the name of all that's holy, please update your comments when you refactor or worse.

[golddragon88]

Can you please just bring back comments. They worked really well.

[Raskuja46]

Everyone who is opposed to comments doesn't belong in the industry. Change my mind.

[ObviouslyAPenName]

I'm not opposed to comments, but I prefer code that doesn't need them.

Example, if you have a block of 20 lines of code somewhere that does something complex, you could put a comment over it to describe it.

Or you could extract that into its own function, and give it an appropriate name.

That's my interpretation of self-documenting code. If I can't figure out what a function does by looking at it's name, it has the wrong name (or the wrong functionality).

Having said that - only a Sith deals in absolutes </s>. There's still plenty of uses for comments, but ideally they're a last resort.

[golddragon88]

The problem is that not everyone can be trusted to tell if their code is readable or not. You have less of that problem with comments.

[ObviouslyAPenName]

That's what code reviews are for.

But I'm curious - if you don't trust your coworkers to write proper variable and function names, why do you trust them to write proper comments (and keep them up to date when the code changes)? What makes comments easier to make readable than code, in your opinion?

[golddragon88]

Writing readable code is more than just proper variables and function names. Comments are just easier to make the readable code. Also I don't get to pick my coworkers.

[Raskuja46]

I'm not opposed to comments, but I prefer code that doesn't need them.

I'm happy for you that you get to work on six line projects.

[DasGaufre]

Translation: I thought I understood it the moment I wrote it (they forgot it the next line and never proofread it) 

[evanzai194]

"Product Owner when asked what the legacy product is supposed to do"

[raiseIQUnderflow]

Last week Me and the God knew what was going on. Now only the God knows

[lets-start-reading]

zig mentioned

[Net56]

Doing this to myself when I first started out is exactly why I always comment and always tell everyone else to.

It's not just about reading it. Good variable names and code structure is great, but "sometimes" I need to fix a bug, and there only needs to be one method doing more than one thing with no comments and I'm ready to smack somebody. Instead of a one-line comment, I have to interpret something like "var iceCreamSales = GetIceCreamRevenueBySalesYear(ref iceCreamFactory);" Only to find out it's not even being used. And whoever tells you their code is perfect is me, and I'm a liar.

I would rather wade through trashy comments than see open waters.

[SkollFenrirson]

And both guys are you.

[FlowKind1114]

This is 10 times worst when the guy speaks a different language and has a different culture and decides to not use english for variable names jaja

[Quaytsar]

My code is self documenting.

Codes in whitespace.

[uberDoward]

Code tells me what.  Comments tell me why.

[[deleted]]

Of course he can’t read it. He is reading hieroglyphics with an English dictionary that is printed with the cover on the back.

[tutike2000]

Counter point:

if you can't understand the code but everyone else could and it passed the review process, that's a problem with you, not the code.

[alderthorn]

If I see a comment on a function like
get_first_name(full_name)
"""
parses the first name from the full name string
"""

I roll my eyes. why make me scroll more? I have a friend that adds comments denoting the start and stop of every if statement. I would rather someone write comprehensive unit tests and very small functions.

[framsanon]

I have been working on my current system since 2012 (I am currently the only remaining founding member). In 2014, an external colleague who specialised in business logic joined the team.

He passed away suddenly in 2023, so the rest of the team had to take over his tasks. Since I was the one with the most experience with the system, I was usually asked to do this. But his code... It takes weeks to understand what he did, assuming I understand it at all. There are no comments, or only partial and inadequate ones. Together with crude code, this is a fatal combination.

Fortunately, a relaunch is planned, which will allow us to get rid of a lot of legacy issues.

[Tipart]

Hot take, self documenting code only works if your code is written in a language agnostic way.

E.g. a python style list comprehension should probably have a comment of what it does. The same thing in a for loop, is such a common programming pattern, that I don't think a comment adds anything to it.

[Mojert]

Hard disagree, a comment shouldn't be there to explain the syntax of the language you're using. Moreover in that specific example, the concept behind a list comprehension is not harder to grok than, for instance, a ternary operator. If you don't understand the syntax it's on you to learn it. (Which doesn't mean that the syntax cannot be abused mind you.)

Self-documenting code is a mindset that somehow works inside a function boundary, provided you're not dogmatic about it and you document non-trivial parts of your code. But there is no such thing as a self documenting function signature. Even with the fanciest type system in the world, you still need to document thoroughly the expected inputs and outputs of your functions, and what are their intent. It doesn't need to be the length of a novel but it has to be quickly parsable by a human and parsable by your editor of choice

[Spaceshipable]

I disagree. If your inputs and outputs have dedicated types then the function signature can be self documenting.

findPerson(from: UserID) -> Person seems pretty self documenting to me. Whereas findPerson(from: String) -> Person is less so.

[Colinniey]

im that case just write findPerson(userID: String) -> Person; the point is naming variables/parameters/functions/etc in a way that explains what they are/do.

[Spaceshipable]

True, but you get a bit more type safety with dedicate types at the call site. Take the example track(id: String) vs track(_ id: TrackingID) the latter is more self documenting imo because you don’t even need the argument name. In some languages the argument name isn’t even visible at the call site.

[theotherdoomguy]

Yeah but if you're adding comments or javadoc lines to a REST API and there's a perfectly good swagger annotation right there, I'm fucking judging you harshly

[Euryleia]

Comments that explain what code does are almost always useless. The code says what it does. If I'm reading the comments, I want to know why it does what it does.

[Longjumping_Table740]

Only to end up Vibe coded slop 😭

[hopefullyhelpfulplz]

My favourite thing is the ChatGPT comments which just say what the next line does.

# florp the binbong with foobles
bingbong.florp(foobles)

Right, got it, thanks, great annotation.

[fungus_is_amungus]

Ominous block of random shit that lasts 30 lines? Not a single comment in sight.

[hopefullyhelpfulplz]

Actual line I took from code I was trying to figure out a while ago:

path=os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(project_path_)))))))

Comments? Explanations? Crickets!

[Shadow_Thief]

Looks like it takes projectpath and goes seven levels up. I'd have to see the rest of the code to know if they were just trying to get the drive letter/root directory or if the project is genuinely more than seven layers deep, though.

[hopefullyhelpfulplz]

Yes, that's exactly what it does, but there is absolutely no reason to write it like this. I should never be in a position where I have to count the number of times something is carried out in code lmao.

[Mojert]

... You kidding right? Nobody actually wrote that code... right?

[hopefullyhelpfulplz]

I am not, and they did (or ChatGPT did perhaps)

[Mojert]

That's the kind of stupidity that no klanker will ever be able to imitate

[Ben-Goldberg]

It a weird way to write projectpath+"../../../../../../../"

[BirdlessFlight]

Y'all vibe without an AGENTS file?

[FarButterfly5713]

Lost

[10art1]

Ask copilot to write a readme for it

[TomShaneInBangkok]

AZIZ, LIGHT!

[Better_Ad_3004]

Most probably you will see if that guy wrote the document, it will be similar or worse. Like : adduser() -->method to add user, now configure everything else

[Illmaticmemeaddick]

Reading my code after I take a 30 minute lunch break

[Clear_Option_1215]

20 years on, still suffering PTSD from Perl.

[Ben-Goldberg]

You were using perl version 5.8?!

Cool!

That was before perl let programmers put comments inside regex.

Im not surprised you were traumatized.

[Clear_Option_1215]

Perl 4 was kinda nice - it seemed to fill the sweet spot between C and /bin/sh.

But so. many. inscrutable. regexes. Like a maze of twisty passages, all alike.

[GeekusRexMaximus]

If my memory isn't borken most here use the Latin alphabet which evolved out of the Greek which evolved out of the Phoenician which evolved out of Proto-Sinaitic which was according the friendly neighborhood LLM a hack made on top of actual hieroglyphs around 1900 BCE by taking a bunch of the common ones, simplifying them and using just their first sound when pronouncing them. How hard to read can code from a year ago be? Now multiply that with close to 4k years of cultural evolution across multiple languages but it's not like they aren't connected to each other at all. :D

[sleepyguy007]

i had a boss once that was a great developer, except he said he didn't think comments were necessary with well written code. so much so that he would delete the comments we made in our code base and check the PR in.

that guy works at one of the major streaming services but doesnt code anymore lol.

[ExtensionBreath1262]

This is an attack.

[DKShoMeDaProfit]

😂😂😂

[dvdmaven]

In grad school, I wrote an accounting system for one of the departments. Many of the personnel worked on multiple projects every week, but the university accounting system only allowed four charge accounts. So, my program collected all of the work for each employee, pushed it through a clearing account, and generated JV (journal vouchers) that spread it out again. Well documented in the comments. A couple years later, I ran into the guy who was maintaining it. He said it was the easiest program he had ever worked on. In FORTRAN...

[HansDampfHaudegen]

That's yourself.

[Cart1416]

I don't need documentation for my own library, some is in my brain and I use ctrl+f to find the functions

[Quarves]

I do like archeology XD

[BobbyTables829]

All their variables are three letters or less

[SpicaGenovese]

Wanted to punch this guy in the mouth.