@fennecbesixdouze1794
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.
@solSwimmer
"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.
@az8560
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.
@davidaraujo2049
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!
@Nonsense116
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.
@fennecbesixdouze1794
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.
@thingsiplay
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.
@u9vata
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.
@wizardite
Can't believe you're a hair's breadth away from Plan 9. I'd love to see that arc.
@theohallenius8882
The only instance I'd advise from using short abbreviations is to be able to find variables quickly in the source code and navigate faster within the source code, can't really do that if all your variables are named i, j, k, o, and when you search it matches every letter in every other word. Also trying to keep them unique is crucial if you want to search and replace variables later throughout the entire codebase, so it doesn't matter what you call them for as long as you can replace them later with one click.
@josebalanza2755
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.
@chromacat248
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)”
@johnychinese
Flip: How many videos do you want released in 24 H Prime: YES
@ThemisGaming
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.
@andzagorulko
Can't wait 'The C Programming Language' on PrimeTime sometime next month
@wgr4329
8:05 In plan9 C they do use this mostly no space in binary operators convention but there is no such thing in Go, but yes gofmt will remove spaces in operators expressions in a style that is used in plan9 C, that's removing spaces to group by precedence order, that's way harder in C because there 15 levels of precedence, in Go there's only 5, so in this expression: 5 + 1<<31 there's no space between 1<<31 because << has a higher precedence order than +, same would apply for 5 + 1*31, in the '+' case the only operators with lower precedence is logical ones, so in this expression x < y+z binary plus are grouped because it has higher precedence order than logical '<', when you understand this idiom it becomes way easier to read expressions with chains of binary operators without adding parentheses noise.
@froge4300
the thing about pointers is so true, whenever i have a loop over an array's contents i have a value like cur_<whatever> or just <whatever> that is the array indexed by the index because its easier to type and theres less that could go wrong
@HrHaakon
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.
@FrederikSchumacher
Reminds me of that other PrimeTime video about how much programmers hate to read code, but love to write code. And I think this happens because there's a disconnect for many people between being a reader and being a writer. As a writer, you're immersed into the context (of what you're writing about) all the time. As a reader, you have to expend effort to get into this context, and expend yet more effort to follow along when context is being modified. Additionally, it's not just the semantic context a reader needs to follow, but also the idiosyncrasies of the writer. Add to this the general complexity of programming, and you get a soup that's easy to cook, but mostly hard and unpleasant to swallow. Sometimes, and I'd say, more often accidentally than intentionally, writers get it right enough and have success. This reader/writer disconnect also seems to present a hurdle to improve one-self as writer for many. Peer reviews could help, especially when peers with alternative idiosyncrasies take part, and the writer in review can distance from code as self-expression and from the immediacy of their own context experience as writer. Unfortunately, this appears to be very hard to learn, and even after years of code reviews I've experienced as writer, they still often leave me feeling defensive. I'd say the biggest change to my perspective on code expression came from applying the Zen of Python repeatedly to my own code and that of others. Reflecting on suggestions I received and gave, and also applying suggestions I made to others to myself. Now I think it's so obvious, if you're a reader take note of positives and negatives of the materials you're reading and apply them to your own writings. If you're a writer, take breaks, switch context, read your own stuff over and over again. But perhaps most effectively, try and explain it to anyone, then observe where you had to spend more time giving context... then add this additional context to your code. I also think this reader/writer disparity also takes part everyday as listener/speaker or observer/actor. It's generally a disconnect between communicating parties, and people only experiencing themselves as one but not the other at any given time.
@tobiasbergkvist4520