"I don't write any comments, my code is self-documenting"

>"I don't write any comments, my code is self-documenting"

Attached: d90.png (644x800, 15K)

Other urls found in this thread:

writemoretests.com/2011/09/test-driven-development-give-me-break.html
npmjs.com/package/is-odd
twitter.com/NSFWRedditVideo

my fucking boss does this
one day I will shoot him in his smug face

Writing my own functions for this simple task?
That is rather inefficient and inelegant.
I'd prefer using npm to get what I need, user.

Attached: 1506887289972.png (645x773, 22K)

Using the C++ STL?
Miss me with that bloated shit, I can do it better with my raw C skills.

Attached: 1526169579755.png (229x220, 6K)

Attached: cancer.png (500x712, 442K)

I actually write more comments than actual code. It's a habit I learned from my Intro to C++ course; our professor would mark off 15 points if our comments weren't descriptive, and 30 points if we didn't have comments at all.

Attached: tarkin01.png (816x816, 933K)

I write comments for myself. So I know wtf I was doing.

same, i'll dig up code from years ago and I'm like wtf is this dark magic.

Comments are often wrong anyway.
The only way to know what something is really doing is reading the code.
"But comments should explain the why!!!"
Why the fuck do I care why someone wrote something? I care what it does and what the end result achieves, who gives a fuck why.

>"Javascript is an interpreted language"

Attached: 2340982068346.png (500x422, 73K)

But javascript is self-documenting

I have a comment
/**
* You're a faggot
**/

>Why the fuck do I care why someone wrote something? I care what it does and what the end result achieves, who gives a fuck why


Picture this: you were hired to fix somebody's shitty code that was written in 2 weeks in a cold sweat. You sit down. You take a look and it's completely spaghetti, there's no way to understand it and your boss wants it fixed ASAP. So you fix it and include comments this time so that the next time you fix the code you can look like a miracle worker and get a pat on the back.

Remember, the shitty programmers always get replaced, and the new guy has to fix the code. To stay on, write comments so that you can understand what you wrote and fix things faster. And be a better programmer without any real skill. It's just good practice.

Code fixes come with commit messages, that's enough.

General documentation (specs - preferably the original customer feature request, how to use some interface, overall architecture design, etc) on the other hand can be valuable, but that obviously shouldn't exist as comments.

What the hell does that have to do with basedboys. If anything, those self hating latte sipping dispshits write nothing but comments. Gender neutral and checked for privilege.

That's a terrible habit. There is a delicate balance between productivity and readability when writing code, and your professor is demanding that you go too far in one direction.

hahahahahahaha

same, but then at one workplace, they thought comments made the code 'dirty', so they'd rather spend 3 days rediscovering what the code was supposed to do instead of just reading a brief description

and they didn't want any optional debug paths so they can easily check the state of the code if something went wrong, like building an elevator without a control panel for technicians
if I knew that most "coders" I'd have to work with are fucking retards I would never have chosen computing...

you have some broken code to fix, how are you going to know what it was intended to do without comments?

> I need comments

Attached: FA2D4992-E7F4-428A-9686-BE8C9B65BF1E.jpg (220x230, 17K)

Writing that many comments doesn't even make it more readable.
Nobody is ever going to read pages and pages of comments, so the comments might just as well not be there.

You should only write a comment when something unusable is going on which future programmers should be aware of when altering the code.
That way they grab attention instead of getting lost in a sea of words.

epic

I it's a lot of lines because I am austistic and keep lines under 80 characters, and for every function I explain what every variable comes from and what it's used for. I do this because occasionally the lead dev, who I initially thought knew his shit but then realized he is a brainlet, has to make changes to my code.

that's just bad code in general.
now if it was well organised code with comments and you were hired to fix problems with it, would you trust comments when it's already established that the code does not do what it is supposed to?

// HELLO WELCOME TO MY "Hello, world!" PROGRAM
// BY DANNY MCKEK, (C) 2018

// first we import the files hahaha
#include // this one is for writing stuff on the console :)
#include // this one is to have the exit code teeheehee

// define constants for cleaner code
#define begin {
#define end }

// main is the entry point of the program
// it takes no argument (void) and returns the exit code (which is an int for "integer")
int main(void)
begin
// now we're inside the function main!!!

// use printf, the function that sends text to the hacker control pannel's output!
// the \n means new line at the end
// prevents having the next hack command on the same line as the output (yucky)
printf("Hello, world!\n");

// set the exit code to close the program!
return EXIT_SUCCESS;

// finished the function!
end

// end of code
// THANKS FOR READING

>// define constants for cleaner code
>#define begin {
>#define end }


REEEEEE

The fuck are you waiting for? Just fuck his shit up now.

Attached: 1508719418550.jpg (500x371, 41K)

Seriously fuck teachers for ever marking down for lack of comments, what a stupid shitty criteria. They either understand the code or don't, asking students to write overly descriptive comments to meet a certain quota is a massive waste of time.

You write tests dipshit

Itt people who don't write tests and don't use their type system try to justify unmaintained and inaccurate out of date comments.

Been working backend dev for 4 years now

i rarely write comments unless its a very complex 50+lines function

I usually have a 3:5 ratio between comments and code at first and then remove half of them as they become self documenting

Comments are great though, I wish to god the faggots who wrote the code I have to debug on a daily basis had written a few comments here and there. Of course, variable names with meaning rather than being a single character would probably help too (most variables have names like "c", "d", etc, I'm autistic but not THAT autistic)

You just told the story of my life.

>writes code so shitty they have to comment it

The popular book "Clean Code" advises that. I always feel that mostly lazy programmers who write anything but self documenting code follow it, because it's easier.

>I prefer static util classes in an OOP language!

not for nothing is your boss user

>I release my code under the GPL

You just have to use variable names that explain what they are (and never re-assign them)

I comment my code heavily because I'm DevOps or something, where programming isn't my main responsibility, and I need to crank out workable solutions with deadlines that are to the wire. Usually I write things well enough that I don't need to look at them for another two years, at which point I wont know what the fuck was going on in my mind when I made whatever half-assed bolted together solution that works with the many legacy systems we're running.

I always feel like the people that talk about properly written self-documenting code either don't write like that professionally, or their jobs give them gratuitous amounts of spare time. Otherwise they wouldn't be able to accomplish it.

People use Clean Code as an excuse to be lazy. Some code is self documenting but some is not. The book doesn't tell you not to write comments where they are needed.
If you have a function that carries out a procedure by sequentially calling a number of functions, that code is most likely self documenting by just reading the function names and the arguments.

If you have a timer and each second you call CheckSensor() that is most likely not self documenting. Sure, you are checking the sensor, but why? Does it have side effects? What is CheckSensor() doing? Just a single line comment will be enough to explain what's going on.

i write comments but not doc comments. how soi am i?

superfluous comments are trivial to remove. adding missing comments are not. most open source code is useless because you could literally write your own implementation in the time it takes you understand what the hell they actually did due to lack of documentation and comments.

>most variables have names like "c", "d", etc
as bad as having dimensional variables without a clue of the dimension used
>int TimeRemaining
>float Mass
>float Distance
turns out one time even the actual programmer who wrote that shit was using time remaining as both minutes and seconds

The worst is when it's painfully obvious what the code is doing or when the program is ridiculously short, which is 99% of the code written in the first two CS classes. I hate professors that demand students write lines of comment for every fucking thing that's going on in the program. Oh yeah here's a comment about my calculation of the area of a square, even though it's obvious as fuck that's what I'm doing haha. I hate college more and more every fucking semester.

Your college sucks, one time I was marked down for too many comments and it was justified.

>write zero comments

Attached: 1523856940721.jpg (249x249, 8K)

>DevOps
what the fuck does this mean
fucking web developers

I'm not a web developer. Well, most of the time anyway. DevOps is what you get when your employer tries to convince you to be a programmer (development) and a sysadmin (operations) at the same time.

how are they even related? one is IT and one is actual work?

>#define repeat do
>#define until(x) while (!(x))
>#define unless(x) if (!(x))

They're related because most developers are clueless about the environments their code runs in. E.g. they have no idea what Active Directory is, let alone how to interface with it, and least of all how to interface with it securely. But that doesn't mean it's not most likely the backbone for a lot of services in your organization, which means someone needs to do some of the heavy lifting to automate things related to it.

Comments are laughed at at my workplace. Read some comments on an older piece of code. They will be inaccurate and they will be a lie.

The same way the function name can be a lie. Just update your comments, update your tests too ffs.

>saved the original programs on floppy disks five years ago

tests are stupid when you're still designing/evolving the system and have to rewrite them all the time

and they slow everything down, you end up with an app that passes your own tests but gets thrown out because it's not suitable for use

you should only write tests when something has a low likelihood of changing, TDD is fucking stupid unless you're making the same website over and over

oh you meant for debugging, and how are you going to reproduce a reported bug in your tests?

it's handy to have debug code that spits out all the important variables that you used during development, instead of writing it for building... then removing it and then having to rewrite it again to debug anything

you can remove all the debug stuff from production when compiling, but that workplace wanted 'clean code'
not maintainable or code that gets shipped in time

Write comments for all public functions and methods. Write comments for classes and APIs. Write inline comments when there is a piece of code that might be cryptic or complicated or use some sort of weird "hack" or lesser known language feature.
Also use better names. Don't call it 'lookup', call it 'resolveAddressToCoordinates'.

That's why you have to have some sort of strict policy in place that says "if you change a piece of code, you MUST update the corresponding comment (if there is any)". When developers get lazy is when this all falls apart.

agree except the last line
call it 'lookup' not 'austisticShitkickingFunctionName'

should be caught in code reviews

>making my code more readable is autistic!
'resolveAddressToCoordinatesUsingGoogleGeocodingApiAndUpdateAccessLog' is autismal. 'resolveAddressToCoordinates' is perfectly reasonable. It's that extra two seconds I save when mentally parsing a block of code that is consuming that function that adds up.
Of course I do this for a living, so I need to code like this.

congratutlations you have been awarded black belt in kode with klossy style.

I'm not sure how to feel about this

you've been doing it wrong.

just get your first job bud?

tests are gay

writemoretests.com/2011/09/test-driven-development-give-me-break.html

44/44 tests are confirmed gay

Types are determined at runtime, how is that not interpreted?

The best documentation is living documentation.

You can write tests within Python type hints.

Attached: 1536294405492.jpg (450x338, 38K)

you can have dynamic types in a compiled language.
common lisp compilers for example generate binaries that do all the type checking during runtime.

but yea. javascript is usually interpreted and not compiled.

Our prof only required basic information related for the assignment: things like your full name, date, name of assignment, our group number and a brief description of what the code does etc etc. I think it's good practice to write all that info at the beginning of the document.

>using a block comment for one line
Disgusting

My coworker actually tried to argue this. He opened up a disassembler.
>user, look at all of this code! Now look at how much less is generated if I just substitute std::vector with my own dynamic array.
Then I asked him to turn on optimizations and the STL version was shorter than his. That being said, fuck the std::map and std::unordered_map. They're really slow because they preserve value aliases so there's an additional indirection.

Ever heard of V8's profiling interpreter? That's the VM warming up, baby!

Do people really not know what DevOps is in 2018?

To be fair, Ansible playbooks don't really need comments. You just name every task.

Except she can't write c and explain this good.

I've fired a few people who had this standpoint. It was after several warnings to follow the code formatting standard we have well documented. Like, they were totally open to solve problems however they wanted to... and one of them was stupid smart in solving problems... just wouldn't code in a way that allowed other people to pick up after them. Fuck 'em.

frog website

npm install is-odd

npmjs.com/package/is-odd

Attached: anon.jpg (750x1000, 35K)

>weekly downloads 1,269,018

My friend and I spent an afternoon looking over the thousands of repos that that guy and his company put out in github. We're convinced it's a money laundering front somehow. There's no way someone can make a living writing nothing but useless code like that for so long. It has to be a front for some other, illegal income source.

Thought about this as well the other day: how much copies of programs can be "sold" since programming is pretty much a business with practically only linear costs. The perfect way to wash money.

May be used as dependencies of other frameworks thus the number of download?

To be entirely fair, you shouldn't need a lot of comments if you name your variables and functions sensibly.

that would even make it worse though

Based trips

Know where you should have comments? Where there's an obvious or simple way to do something, but you found out that there's some complication or subtlety or corner case or whatever that means you can't/don't want to do it that way. If you fall for the self-documenting meme you (or others after you) will be forever discovering something that seems silly and overcomplicated, simplifying it, and then rediscovering whatever problem it was that led you to not do it the straightforward way to begin with.

I don't write any comments in case someone decides they are racist/sexist/misogynistic/toxic somewhere down the line.

it's a made up word for geeks to roleplay as specops and sound more important than they are

Yeah man, nerf guns are so rad, totally. Or maybe you're wrong?

Triggered basedboy.

>Google Geocode

Don't get me started on address normalization, user.

I don't write code. My comments are self explanatory

Attached: pepé.png (1080x1716, 106K)

I often don't comment my code, and it's not even self-documenting. If it was hard to write, it should be hard to read too.

Or, you're just wrong?

>24 commits
>4 authors

I don't write any comments. My code isn't self-documenting.

>open work-in-progress code by colleague
>nearly every other block of code is commented out with no explanation
fuck you jason, you don't get to complain that im not commenting on the right things if you hand me code like this you bitch

Attached: chiyochan.gif (220x200, 143K)

FUCK! I do not want to be living in this time line :(
Source on lisp, you sure it isn't compile time?