[Webinar] Reality Check: Who determines what Clean Code is anyway?

Hi all,

On February 22nd, come and join us for another exciting webinar!
Gabriel Vivas, Product Manager, will talk about how Clean Code is rooted in programming history, and attendees will gain practical tips for separating true engineering practices from coding advice hype.

Mark the date!

Title: Reality Check: Who determines what Clean Code is anyway?
Date and time:2024-02-22T16:00:00Z
Speaker: Gabriel Vivas, Product Manager

Who should attend the session: Developers and Managers

Register now!

Interested in the topic but can’t make it to the live webinar? Register here to receive the recording of the session.

See you there!

Hi all,

Thank you to everyone who attended our session yesterday. You can find below the questions and answers from the webinars, as well as all the resources mentioned by the speaker throughout the presentation.

Q: Is Clean Code a set of recent practices and examples shared and accepted within a closed community of developers, i.e. development team?

A: Sometimes that is how it starts. It will often will start with a community of practitioners. However, as an industry we have enough experience now to be more general. We know enough to have world standards, we touched upon some of these in this webinar. Before trying to do your own thing, be sure you are aware of well recognized practices.

Q: What would be the key Clean Code elements you would apply to any projects ?
A: One approach that we see working well is to use SonarCloud with the default settings and that will give you a great baseline to build on. This will help you make sure as you add new changes, they are clean.

You can then tweak things from there to meet your particular needs in terms of which rules matter most to you.

SonarCloud is free to use for opensource projects. You can also get a trial for closed source projects. Both can be found at sonarcloud.io

Q: Will the deployment of AI promote clean-code programming?
A: Code generated by AI is based on ingesting a vast amount of existing source code. Since a lot of existing code isn’t clean, AI-generated code shouldn’t be assumed to be clean. The code still needs to be understood though, so the importance of clean code doesn’t diminish.

We recommend using the Sonar Clean Code solution as it offers a responsible path toward adopting AI code generation. Embedding SonarLint along with SonarQube/SonarCloud as part of your code development process and Continuous Integration pipeline ensures the code being produced is consistent, intentional, adaptable, and responsible. This approach ensures the generated code meets the code quality standards and aligns with best coding practices. By combining the strengths of AI and Clean Code solution from Sonar, customers can get assurance, reduce risk, unlock the full potential of code generation, and usher in a new era of software development that is both innovative and secure.

Q: Clean code is the way to go but we can face some reluctance from teammates in adopting Clean Code practices. How can one approach others and be effective in showing the advantages of clean code?
A: It is really related to the attitude they might have. Maybe they just care about their code. Have a discussion together and find a solution together. They need to code for the team and not for themselves.

Q: How Clean Code evolved from time to time? What changed and what didn’t change?
A: Surprisingly, not much. Well, you can see the language syntax and tools have changed quite a lot. We talked about FORTRAN, punch cards, and big IBM mainframes. But, code that be read and changed, is mostly about humans. So I would say we are getting closer to more empirical definitions, but in principle, it has changed very little.

Q: How are you ensuring that you as Sonar are following the best path in the evolution of clean code and not becoming someone who is later on saying that your assumptions got outdated?
A: We are taking the pragmatic approach; what we recommend is what Sonar users have been using effectively. We create rules and analyzers for many languages, and this is a synthesis of our practical experience. Ultimately, the proof would be in real-world use, you can try it yourself in our products for free; take it and try it! Then come to the Community and share your feedback.

Q: How can you convince some dev teams to use sonar when most of the IDEs now have built-in code linter?
A: You can begin with SonarLint, directly in your IDE, IntelliJ, VSCode, or what you use. SonarLint it’s open-source and free to use, it is also really tied into your workflow. It’s super easy and doesn’t create friction, it looks like another linter in your IDE, but it’s doing deeper work. From there, you can then also use SonarQube or SonarCloud to have a sort of safety net in the CI/CD environment, shared by the team. We do recommend doing all of that, but start where you can.

Q: Where does security fit within Sonar’s principles of Clean Code?
A: We think Security is more like a positive impact of good code, than something you find inside the code itself. So in Clean Code you always sanitize user input, always use recent strong algorithms to protect privacy, always conceal secrets, etc. And this happens to be critical for Security. So we believe Security is related to the benefits of Clean Code. You can see this in our products, we show how specific code issues can have an impact in the Security of your software.

Q: Does the tool enforce OWASP best practices?
A: Most OWASP practices are about security concerns, so the short answer is yes. We do it the Clean Code way, which means you should always sanitize your input, always ensure your ciphers are good, no secrets are leaking, etc. If you want to learn more, we have several pages on our website that attest to this.

Q: A lot of our discussions get mired down in discussions of individual pieces of syntax instead of higher-level practices to keep things subjectively “clean”. This causes people to consider this partially bike shedding - any tips for avoiding this?
A: What has happened for a very long time is that people have obsessed with individual choices of how to do things (should I put my braces in the same line or below? etc). What we feel at Sonar, and it has been proven in empirical research is that it doesn’t matter that much. Everything is roughly the same, except it should be consistent, meaning if you decide to go for something all of the code base should be like that, and the authors as well, and the code base should stay consistent over time. And you get bonus points if that style is consistent with your language ecosystem.

Q: Is Clean Code the next certification or proof for a developer to land an awesome job?
A: [Speaker] I hope not. I would hope Clean Code to be about developers/engineers doing their best, as masters of their craft. Owning code value, without somebody else telling them what code should look like. Only developers can have an impact on the code. Let’s keep the focus on the code.

Q: Developers usually resolve to quick solutions/fixes due to tight deadlines; How can we continue delivering fast while maintaining clean code?
A: We believe that the only to way to go fast sustainably is to go clean. One common fear of having a high standard of quality is that you’ll have to deal with all your messy or legacy code, but you can focus only in the code you are actually producing. We call this “Clean as You Code”. Also you should start early, like in your IDE with SonarLint. You fix it as you type it, even before anyone else sees it. This is super effective, and saves you an anourmous time from having comments in PRs, to solving problems later in production. You waste a lot of time putting out fires all the time. Also set a Quality Gate as safety net, and only promote clean code, this is how you save time daily and ensure your codebase continues to be usable in time.


Find here all the resources presented during the webinar:

Google Trends

Blog post
“It’s probably time to stop recommending Clean Code”
Source: It's probably time to stop recommending Clean Code @ Things Of Interest
Reddit comments: https://www.reddit.com/r/programming/comments/qs8j0z/

“Clean Code: A Handbook of Agile Software Craftsmanship”
Robert C. Martin. 2008. Pearson, 464 pages. ISBN-10 9780132350884

“Bulk core in a 360/67 time-sharing system” by Hugh C. Lauer, 1967

“​​Lecture series on nonlinear least squares” by George D. Byrne, 1973

“Go To Statement Considered Harmful” by E.W. Dijkstra, 1968
Communications of the ACM Volume 11, Number 3. March 1968
Cartoon XKCD
Source: xkcd: goto

“On the criteria to be used in decomposing systems into modules” by D. L. Parnas. 1971

“Structured design” by Larry Constantine & Ed Yourdon
IBM System Journal, Volume 13, Number 2. 1974

“Tidy first?” by Kent Beck
O’Reilly, 2023. 99 pages, ISBN-10 1098151240

“Programming Style: Examples and Counterexamples” By Brian W. Kernighan and P. J. Plauger, 1974

“The Elements of Programming Style” by Brian W. Kernighan and P. J. Plauger, 1974
McGraw-Hill, Inc.

“Refactoring” by Martin Fowler, 2018

“Sub-second acceptance tests” by Aslak Hellesøy, 2018
Source: https://www.youtube.com/watch?v=AJ7u_Z-TS-A

Blog post
“What is Clean Code?”
Source: What is Clean Code?