🚀 Seven Ineffective Coding Habits of Many Programmers (Kevlin Henney)

[piotrkubowicz]

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!)

[okannie-ymyx]

using a photo editor with macros when programming to visualkze the structure of a program. + debugging

[AB-iist]

German does not have a longest word. You can concatenate as many words as you want following some grammar rules.

[dmitritikhonov]

I like it how the talk triggered some people. 😄

[LeutnantJoker]

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.

[MickaelVest]

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, ...)