05:30 Why do programmers need habits? 07:00 1. Noisy Code 08:00 - adding words does not make code clearer 10:50 - comments 15:00 2. Unsustainable Spacing 16:30 - how people read 18:10 - clean (visual) design 20:50 - laying out method parameters 22:00 - styles stable during renaming 26:40 3. Lego Naming 32:00 - too formal naming 33:20 - meaningless words 34:00 - naming exceptions 37:15 4. Underabstraction 38:15 - stringly typed systems 40:15 - lack of domain language 41:50 5. Unencapsulated State 46:45 6. Getters and Setters 48:15 - pairing of get & set 48:30 - get as noise-word, expecting side effect 49:30 7. Uncohesive Tests 51:30 - 1-1 mapping of code-test
I really recognized many of my habits, i used to have at the beginning of my career. Working in a team helped to see other's habits and to eliminate some of my own!)
20 MInutes in and all I've gotten out of this is bad jokes, someone claiming commenting code is bad because incompetent programmers write stupid comments and then claiming spaces are evil, proving that by an example that happens maybe 1 in 10,000 lines of code and is usually a tooling issue and a none-issue on wide screen monitors of today... jesus dude... this is the worst talk about coding practices I've ever watched in my life. Can you get ANY more trivial. If I don't like the code layout, I run a tool over it, wait until I'm done with my work, reformat it again to the company standards and check it in. that takes about 5 seconds. We're not writing code on typewriters. Edit: remainder of the talk is about naming conventions... agaain, that's down to stupid people, not bad habits, and finally the age old "tooling is bad".... Yeah.. dude.. I know for sure I'd never want to be anywhere near you at work. You focus on such trivial crap while the code your actually did write in this looked horrible.
Honestly that myth about "good code not needing comments" needs to die ASAP. This is coming from book authors who obviously never had to work in a team, and never had to maintain something. I will agree that a comment saying "Displays the string" is a bad comment. And bad comments are noise, yes. But not all comments. And you should absolutely document your inputs, your outputs, your properties, etc. And inside your code (like inside the functions), comments should be sparse but can hold a lot of value. Also you should abso-f*ing-lutely add comments to give credits to people you take stuff from (github repo, SO answer, ...)
@@GeorgeTsiros If you ever have to fix production bugs or if you ever credit the things you copy paste to their original author, you will find out all by yourself
05:30 Why do programmers need habits?
07:00 1. Noisy Code
08:00 - adding words does not make code clearer
10:50 - comments
15:00 2. Unsustainable Spacing
16:30 - how people read
18:10 - clean (visual) design
20:50 - laying out method parameters
22:00 - styles stable during renaming
26:40 3. Lego Naming
32:00 - too formal naming
33:20 - meaningless words
34:00 - naming exceptions
37:15 4. Underabstraction
38:15 - stringly typed systems
40:15 - lack of domain language
41:50 5. Unencapsulated State
46:45 6. Getters and Setters
48:15 - pairing of get & set
48:30 - get as noise-word, expecting side effect
49:30 7. Uncohesive Tests
51:30 - 1-1 mapping of code-test
You the real OG
I really recognized many of my habits, i used to have at the beginning of my career. Working in a team helped to see other's habits and to eliminate some of my own!)
using a photo editor with macros when programming to visualkze the structure of a program. + debugging
I like it how the talk triggered some people. 😄
😂 I need table of contents
German does not have a longest word. You can concatenate as many words as you want following some grammar rules.
ngl i liked the first version the most
20 MInutes in and all I've gotten out of this is bad jokes, someone claiming commenting code is bad because incompetent programmers write stupid comments and then claiming spaces are evil, proving that by an example that happens maybe 1 in 10,000 lines of code and is usually a tooling issue and a none-issue on wide screen monitors of today... jesus dude... this is the worst talk about coding practices I've ever watched in my life. Can you get ANY more trivial. If I don't like the code layout, I run a tool over it, wait until I'm done with my work, reformat it again to the company standards and check it in. that takes about 5 seconds. We're not writing code on typewriters.
Edit: remainder of the talk is about naming conventions... agaain, that's down to stupid people, not bad habits, and finally the age old "tooling is bad".... Yeah.. dude.. I know for sure I'd never want to be anywhere near you at work. You focus on such trivial crap while the code your actually did write in this looked horrible.
Yeah, this guy seems like he is stuck reminiscing on times in which his knowledge of ancient system architecture was relevant.
Thanks for saving me the time. I was getting a sinking vibe...
Honestly that myth about "good code not needing comments" needs to die ASAP. This is coming from book authors who obviously never had to work in a team, and never had to maintain something. I will agree that a comment saying "Displays the string" is a bad comment. And bad comments are noise, yes. But not all comments.
And you should absolutely document your inputs, your outputs, your properties, etc. And inside your code (like inside the functions), comments should be sparse but can hold a lot of value.
Also you should abso-f*ing-lutely add comments to give credits to people you take stuff from (github repo, SO answer, ...)
show me one good comment
@@GeorgeTsiros If you ever have to fix production bugs or if you ever credit the things you copy paste to their original author, you will find out all by yourself
@@MickaelVest you don't even have _one good comment_ to give as an example?
one comment?
int add_integers (int first, int second)
{
int sum = first + second;
return sum;
}
The input and output are documented by their type and their name.
@@nickheyer ... _what?_