LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
Presented By: Mansi Babbar
Basics of Writing
Lack of etiquette and manners is a huge turn oﬀ.
Respect Knolx session timings, you
are requested not to join sessions
after a 5 minutes threshold post
the session start time.
Make sure to submit a constructive
feedback for all sessions as it is
very helpful for the presenter.
Please keep your window on mute
Avoid leaving your window
unmuted after asking a question
● easy to understand the execution ﬂow of the entire application
● easy to understand how the diﬀerent objects collaborate with each other
● easy to understand the role and responsibility of each class
● easy to understand what each method does
● easy to understand what is the purpose of each expression and variable
● easy to extend and refactor
● Classes and methods are small and only have single responsibility
● Classes and methods are predictable and work as expected
● The code is easily testable and has unit tests (or it is easy to write the tests)
● Tests are easy to understand and easy to change
Universal Principles to follow
● Follow SOLID principles
● Follow a Design Pattern if it ﬁts the problem space that you are trying to solve.
● Follow Law of Demeter
● Follow TDD (Test Driven Development)
● Functions should be short as possible
● It should follow SRP (Single responsibility principle)
● No side eﬀects
● No nested control structure
● Prefer less number of arguments
● Must only do what the name suggests and nothing else
● Should either do something or answer something, but not both
● Classes should contain variables and functions that do one thing (SRP)
● The name of a class should describe what responsibilities it fulﬁlls
● Do one thing (SRP) : It is forbidden to create classes that have many
● Variables should be private so that we can change their type or
implementation when required
● Classes should be small
● Classes should provide abstraction
Cleaning Error Handling
● Code should be both clean and robust, it should handle errors with
grace and style.
● Catch everything. Better to be safe than sorry.
● Be informative. Return Exceptions instead of Error Codes. Each
exception thrown should provide enough context to detect the error
root cause and location.
Cleaning Unit Tests
Clean tests should follow F.I.R.S.T principles:
● Fast: Tests should be fast. They should run quickly.
● Independent: Tests should not depend on each other. One test should not
set up the conditions for the next test.
● Repeatable: Tests should be repeatable in any environment. They should
run in the production environment, the QA environment, and even on your
laptop while riding home on the train without a network.
● Self-Validating: Tests should have a boolean output. Either they pass or
● Timely: Tests need to be written in a timely fashion.
● The only truly good comment is the comment you found a way not
Don’t comment bad code, rewrite it
● Don’t comment bad code, rewrite it
● Explain your intention in comments
● Warn of consequences in comments
● Never leave code commented
Cleaning Formatting Skills
● When people look into your code, you want them to be impressed
with the neatness, consistency, orderliness and attention to
detail that they perceive
● You should strive to keep your lines short. You should never have to
scroll to the right.
● A function that is called should be below a function that does the
● Each line represents an expression or a clause, and each group of
lines represents a complete thought.
We can simple remember these points while writing code...
● KIS : Keep It Simple
● DRY : Don’t Repeat Yourself
● YAGNI : You Aren’t Gonna Need It
● Composition over Inheritance
● Favor Readability
● Practice Consistency