Programming as a career

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

Classic or dud: late night email from colleague cc-ing management saying he can’t figure out something you gave him a few weeks ago and it is crashing and you need to put in more error checking etc. ( because his time and productivity etc)

Well this has been sorted for now.

# get password via terminal without echoing
password = STDIN.noecho(&:gets).chomp

reasonable, right? sentence in english explaining the cryptic command that follows. i don't get the "document WHY not WHAT" review comments i always get.

coming new to this code, debugging it later say, such things let you understand which part does what without having to decode the code. = useful, especially if you're in a mixed ability team.

also, review comments from people you haven't asked for reviews, classic or dud?

Leaning towards dud.

Codesplainers gonna codesplain.

If people would just put in fucking comments saying what they were trying to do and what their expectations were, basically defining the contract they're trying to fulfill, it would be about 8 billion times easier to identify logic mistakes than it currently is.

https://www.hillelwayne.com/post/what-comments/

i have an issue with that

> //f.ex $F1a3

f.ex? for example? what's wrong with 'ie' or 'eg'?

(my whole script only exists because someone checked in an aws kms encrypted key without explaining how it was generated, and 3 years later we needed another - lack of documentation again)

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