Programming as a career

I can see where the anti comment review on that is coming from. The comment duplicates stuff that’s in the docs, right? It’s not a “trick” that depends on undocumented behaviour (like the fact that piping to xargs is a way to trim leading and trailing white space?! Did you all know this?!). It’s just something that’s not obvious from reading the code. That’s not where I draw the line and your point about mixed ability teams is a good one, but it’s not a terrible place to draw it.

Whoa, xargs trick is neat!

I am old. I still use xargs -i and never switched to -I

Also can never remember that xargs idiom using the shell trick.

Ah, xargs -0 will keep the whitespace

Feel like comments should be judged on their practical effects rather than from some philosophical position. If it takes 2 minutes to figure out a chunk of code without comments and 10 seconds to figure out the code with comments, I don't care how "obvious" or "self documenting" the code itself is, the comments are good.

otm

I say this as person who long ago took a course - in Pascal! - nicknamed "Commenting For Credit" in which people were expected to do things like

  i := I + 1; //increment I 

(input wants to uppercase every i)

 i := i + 1; //increment i again

Next topic: git commit messages.

//increment topic

ruby doesn't let you i++. spent a chunk of sunday looking at cryptic error message and not seeing the problem.

Feel like comments should be judged on their practical effects rather than from some philosophical position. If it takes 2 minutes to figure out a chunk of code without comments and 10 seconds to figure out the code with comments, I don't care how "obvious" or "self documenting" the code itself is, the comments are good.

Can we attach this to everyone's monitor?

I think I only write comments that are at least 100 words long

I'm the only one reading my code/commenting so too many of my comments are targeted at my osteoporosis of a memory, e.g.,

// The + 16 offset is event type, commenting so I don't forget it yet again
// The + 16 offset is still event type, it appears I forgot it again

(4000 lines apart, to be fair, and not my code but decompiler output)

public static final int EVENT_TYPE_OFFSET = 16;

trust me that's not feasible in this thing, it's certainly possible but this is 240K lines of code and I can't just ctrl-f

Btw, my posts from a few weeks ago was about colleagues who are part of the development process and are participating in alpha testing but seem to want to behave as if they are end users and are shocked - shocked! - when something breaks. Perhaps this is a touchy subject.

Because no one wants to be that guy that breaks things.

But only the other hand there is the short-term/local/pre-mature optimization of being fast on the send button with "It broke! Nothing should ever break!"

"Strike mine eyes from my face!"

"I have reported thy breaking to mine Lord of Unbreakability. My day's work is done, now I shall take leave and rest for the nonce."

But only the other hand there is the short-term/local/pre-mature optimization of being fast on the send button with "It broke! Nothing should ever break!"

this is me :(

Knew it!

caek’s link is otm

I am in favor of breaking down functions to component parts when they’re overly long or complex. This is a necessity in code of any length, especially when it makes scope of variables clear and you’re doing a specific manipulation of data that is secondary to the purpose of what you’re writing. You don’t need inline parsing of object A into object B if what you’re actually doing is some sort of calculation.

The primary use of functions is to encapsulate code that could be reused somewhere else. If you can add a few comments and make it clear what you’re doing in the primary function, and you’re not reusing anything, just add comments.

Same for code paths that are going to end up calling all functions — why are all of them separate functions if you call every one of them 90% of the time? You’re just replacing comments with function names, and outside of the context of reading *all* of that code, I have no idea what replaceAllInstances does. Instances of.. the one argument to the function? It’s method signature as comment

Well said.

Kevlin Henney to thread

World’s Finest Commit Message:

Merge remote-tracking branch 'origin/master'

smh

SMH CARD

https://www.youtube.com/watch?v=X23v5_K7cXk

speaking of commit messages

https://www.twitter.com/gitlost

lol

always happy to see that account again

this component test, two of the 'expected' fields are actually a comma separated list of additional tests and a parallel comma-separated list of the expected values for these tests.

Defensive Programming: C/D

Depends what it is… but I’d rather have good tests which catch any failures in most cases I would say.

iirc Go tries to push defensive programming as a default

iirc the main point of defensive programming is handle all the error conditions *first* then the code does what it’s supposed to

it’s smart imo, because happy path programming is terrible

worst mess up we've had here recently, one that made the papers, was component C relying on previous component B for validation only to then add component A as an input path and component A didn't bother.

in short: trustno1

Innocuous irrational anger: typos in method/var names that don't get fix and propagate throughout the system wherever the thing is called - check_intant_update_user_permission

intant_update_user_permission = False
...
return intant_update_user_permission

how can you even c+p all that without noticing?

intant_karma.Said(“Knock You Out”)

hey my display name is relevant

> don't get fix

you never fix

who is screaming FIX at my code. i will never fix.

OMG we have a column in our DB called loyality_discount.

that’s right

I think about this Reddit thread a lot pic.twitter.com/w2QxYJ2kx6

— Sy Brand (@TartanLlama) August 20, 2020

when that thread was making the rounds I did a lot of mumbling “oh no”