Creator of Go on Software Complexity | Rob Pike | Prime Reacts

The descriptiveness of a variable name should be proportional to its lifetime. That's why it's fine to use "i" in tight loops - because the variable has a very short life span.

resolve, reject is actually much clearer than res, rej. I can tell you this personally because I've read other people's code and realized they think res means "result" or "response" and don't realize it's a callback function. I use abbreviation all the time, e.g. "amt" for "amount", "len" for "length", "args" for "arguments" etc, especially anything that's a reference to a common abbreviation in use in unix utilities or POSIX standards. I also don't shy away from 1 or 2 letter variables for inner variables and things controlling control flow (e.g. if I'm orchestrating some concurrent logic in Go and I only have one main communication channel, it is often named "ch"). But for something like "res" that could refer to so many different concepts (result, resolve, response, resume ...), I avoid it.

"clear use of function pointers is the heart of object-oriented programming" absolutely true. Ffmpeg, a C program, is object-oriented because of how it uses function pointers. It also does object-oriented better than most actual OO languages.

30:32 - so true !! In college, I had a professor that made us do EVERYTHING in Python, and he would give us template code, meaning, we had to complete it but we couldn't change what was given as a base. And he would use Classes in Python for every single thing, and I would just get so MAD because the code was so simple but because of this, the code would be so slowwwwww. Because of that, in one of the projects I delivered the project with two codes, that did the same thing, but in one I replace all objects with dictionaries, and in the delivery file I also appended a graph with a profiler analysis of both codes. That felt good!

I'd say that for the sake of search it's better to name things uniformly and without abbreviations. It's much easier to find anything in project related to 'address' if it's fully spelled than to try all kind of silly abbreviations which can come to mind to different people. It also has an advantage of spell-checkers validating that you don't have a typo. Especially useful if the people working on the project change often, and some of them are just juniors from unknown countries whose knowledge of the project domain and English skills are lacking.

Can't believe you're a hair's breadth away from Plan 9. I'd love to see that arc.

res and rej versus resolve and reject The shorter one differ only in one letter. Also searching the text with longer names is easier. It is fine to abbrev, but I personally prefer slightly longer names, depending on the situation off course. There are no hard rules.

Can't wait 'The C Programming Language' on PrimeTime sometime next month

Apparently its a hot take around these parts but I like complete naming and don't like abbreviations. I've spent more time in C++ than I would've ever liked to have and it drives me up a wall how some of its naming where it begins to fail to even read like english anymore. It's painful, the few times I have to do something with C++ the number one thing I'm actively despising going in is the abbreviations. If it was just the full name I probably would be able to figure out what the purpose of the thing is. But I can't and now I have to pause and go read code or docs because someone couldn't take the two seconds to type 8 more characters. I'll die on the full name hill.

The most meaningful point about abbreviations is actually not about abbreviations per se, but about consistency: The thing about abbreviation is that there are no standard conventions for how to abbreviate things, and this can cause naming inconsistencies when different programmers abbreviate similar concepts in different ways in different parts of the program. I often choose to use the full name of things simply because it sidesteps the question of exactly how to abbreviate it. This only matters of course when the concepts have a wide scope, e.g. method names or fields in public interfaces etc.

I comment a lot - actually sometimes even add ascii-art drawings when needed. I think coding enough long in assembly teach you to comment and comment well. These are the things I do: - Typographic comments that mark blocks: like "// preparation" and "// windup" instead of creating methods for that only called from this single location. It makes readable code! - Documentational comments for methods and structures are very useful - Writing out why you choose and algorithm is very useful - Sometimes explanation of invariants or even the algorithm can be useful (this is where drawings can happen mostly - mostly for new data structures) - There are cases when I use "markers" - like "this works because of (***)" so that you can totally search for (***) held up as invariant somewhere. You can say "oh likely is bad design" but this also works in performance optimized codes and edge cases and sometimes you cannot make a more readable version but this still works and is very useful. - What about other hard-to-convey-in-ode information like "(// O(n) because despite this being a loop in a loop total element size at this point is linear to original input data) ??? - Also perf characteristics I sometimes mention in documentation comments - but also contracts for the caller genereally. +1: Actually I do prefer even the wrong comments compared to none if I can access git blame. Its a fallacy to think "code should be self-explanatory" because it might be self explanatory to someone and give endless headache to others (or even yourself) later. Especially with feature or code creep around that area where every small change in all the small PRs end up creating a monstrosity that lose its meaning. I saw that happening and comments HUGELY help. If they are not what the code says - that is indication of a bug: its either the comments bug, or worse: the code is buggy. In both cases worth investigating. Also keep in mind that the argument "the compiler does not check the comments" does not really hold up: neither the compiler checks how you name things and the same article puts a heavy effort on naming. I say this because I literally saw endless many times where naming and content go out of sync.... like "railConnectionMap.get(c)" for example ADDING c to the map if does not exists before.... who made that change was a total idiot, butt added the code there which is crazy and I got heavily surprised that this call not only always succeeded but makes it possible to out of memory the whole process :D It was once a simple getter, but it got "other shit" into it and the name stayed. I knew things where a checkRegex(r, obj) got to have a side effect of connecting to a database and do stuff related on user role - sorry I was like whyyyy why not rename if you do these kind of shit? Mostly good content, but sorryicantfukinreadwithoutcamelorsnakeorsomepropercase exceptshort.... and sorry but I find comments very usable. It is sad people are not excercising good commenting.

the creator of go, I wonder what is take will be? 🤔

PL/SQL has a very important differentiation between functions and procedures. If you have to write stuff in it, it's really helpful to know the difference immediately, it saves you confusion.

Loved this article! Especially the focus on data. That approach can really make a night and day difference in a program. Data is king.

the thing about pointers is so true, whenever i have a loop over an array's contents i have a value like cur_ or just that is the array indexed by the index because its easier to type and theres less that could go wrong

On the use of abbreviations in variable names, I worked with a guy who took that to a whole new level. Some of the notable abbreviations we had to change all over an API were dtBth for dateOfBirth, veh for vehicle, and clnt for client. It happed so early on in my career that now I, to a fault, name things way too long.

“e” certainly isn’t confusing when sitting right next to the definition. But if you find it at the bottom of a 200 loc method, you’ll find yourself going back and forth to check what things are.. it hurts readability because you cba to write the thing in its entirety to begin with. Just my two cents

Flip: How many videos do you want released in 24 H Prime: YES

I am going to be bold and try to clarify 32:55 - 33:30 for anyone who is wondering. What Rob Pike means is that you should encode your data into a format that is easy to address in your code, rather than adapting all your code to the data. By doing so, you reduce the amount of times you have to deal with the complexity of the data. In the parsing table example, encoding the grammar of the programming language into a parsing table once saves you from dealing with complex grammar rules every single time you manipulate the data. Think of it as centralizing the complexity of the data into a continuous block of logic, instead of having bits and pieces all over your program.

13:15 my brain interpreted the parenthetical as being unrelated to the rest of the sentence like “The Sun is a star located in the center of our solar system. It radiates energy derived from a process known as “nuclear fusion” (my family died in a drunk driving accident 5 years ago)”