Reasons & Ways to Improve Code Quality • Venkat Subramaniam • GOTO 2021

This presentation was recorded at a GOTO Night 2021. #GOTOcon #GOTONight

Venkat Subramaniam - Author of "Programming Kotlin"

ABSTRACT
As programmers we crank out code day in and day out. In the pressure to deliver faster and to keep up with change, it's easy to forget about code quality. Over time, we may not even realize how much the code has deteriorated except that we feel the pain moving forward, as with each line of code we touch gets harder and slower to change.
We will discuss the reasons to maintain good quality code and ways in which we, each one of us, can be part of creating quality code. [...]

TIMECODES
00:00 Intro
02:45 Why should we care about the code quality?
04:47 First law of programming
05:07 Economic impact
05:24 What's quality code?
06:44 Ways to improve
06:51 Honor SLAP
12:05 Favor high cohesion & loose coupling
14:18 Reveal intention
17:28 Avoid primitive obsession
21:12 Avoid clever code
23:16 Comment "Why", not "What"
24:27 Give good meaningful names
28:44 Do tactical code reviews
29:47 Outro

Read the full abstract here:

RECOMMENDED BOOKS

#Programming #CodeQuality #QualityAssurance #Quality #QA

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[fatihunal]

>> 21:30 --> :) :) "I wrote a code and nobody understood" normally not a reason to proud of but personally most of the developers feel like that

[gabosol]

I really enjoyed the example of the "Avoid primitive obsession". Even though streams and functional programming is not new in Java, still it's not the first natural approach to solve a problem for me. Sometimes I know a code can be improved in this fashion but that requires to slow down and revisit the available methods. I'm learning little by little that is the best. Instead of priding myself for ending something fast, it's better to feel well because I know the code looks better.

[VolodymyrFrolov]

Venkat is a brilliant presenter, as always!

[csexton]

The function length it does matter but its by use case and responsibility. Game programming and embedded systems, its very common to see long functions because they are trying to avoid adding to the stack and increasing performance. This is the minority though but an example use case. Another example is writing a function which has a long body, abstracting out the parts doesn't provide any additional readability, doesn't reduce complexity and doesn't provoke DRY. To me 100% its use case dependent....

[raghavanaliassaravananm]

This was the presentation he made in the year 2009, but published after 12 years!? Slide for Avoid primitive obsession shows the date as 09/30/2009 at the bottom right!

[kitkarson]

When I see Venkat, I just like the video because I know it going to be awesome.

[web_shivam]

This is absolute amazing session
Loved it ❤🙌

[andrueanderson]

"Class Names" - I hate when presentations like this assume modern class-based object-oriented programming. My first law of programming is avoiding class-based OOP or you'll have to start by implementing the "Atom" class to avoid duplication. Save yourself the trouble and reach for the functional approach from the start.