<\/p>\n
And for each piece of code, the developer\u00a0does an analysis of the current problem to\u00a0resolve, its background and the opinions of his team could influence a lot its choices, and the way how the code is developed.<\/p>\n
After writing a code and committing it.\u00a0 be sure that it will introduce a debt that\u00a0the project maintainer and developers have to pay sooner or later.\u00a0 To minimize the debt and make the task easy for all the project developers, it’s better to acquire\u00a0some basic good habits to make the code clean from the beginning.<\/p>\n
1 Naming<\/strong><\/p>\n Sometimes we spent a lot of times just to understand the utility of a variable or a function because it’s named a,b or x. And if from the beginning it was named with a clear and significant name, its meaning will become obvious.<\/p>\n Good a significant naming that follows a naming convention help:<\/p>\n 2 Visibility<\/strong><\/p>\n Narrowing visibility is a good practice because doing so promotes encapsulation. Reduce the scope to a minimum, will help the user of your code. Indeed he will know which code could be used from outside a class.<\/p>\n Making all the class methods public will confuse the user, and it will hide the class contract. And in this case, we need a documentation to know which methods could be used.<\/p>\n 3 Parameters<\/strong><\/p>\n A function that takes more than five parameters indicates one of two problems:<\/p>\n There are some good gains to be had by doing this:<\/p>\n <\/p>\n 4 Size<\/strong><\/p>\n Methods too big are not easy to maintain and understand.\u00a0 Here\u2019s some advice about the length of functions from the\u00a0linux coding style web page<\/a>:<\/p>\n <\/p>\n 5 Number of\u00a0local variables<\/strong><\/p>\n Methods, where NbVariables is higher than 8, are hard to understand and maintain. Methods, where NbVariables is higher than 15, are extremely complex and should be split into smaller methods (unless\u00a0they are automatically generated by a tool).<\/p>\n 6 Avoid defining complex functions<\/strong><\/p>\n Many metrics exist to detect complex functions, NBLinesOfCode, Number of parameters and number of local variables are the basic ones.<\/p>\n There are other interesting metrics to detect complex functions:<\/p>\n The max value tolerated for these metrics depends more on the team choices, as there are no standard values.<\/p>\n Let\u2019s search for possible functions to be refactored:<\/p>\n <\/p>\n 7 Formatting<\/strong><\/p>\n Programming style and indentation can be defined as the way you follow to organize and document your source code. Code indentation is a part of style and it is more of aesthetic interest. If we follow a\u00a0proper style guide and indentation then a program can be just like a POEM. And the reader will be comfortable enough to SAIL through it and understand the meaning. As we know a proper code indentation will make it:<\/p>\n The purpose of code indentation and style is to make the program more readable and understandable. It saves lots of time while we revisit the code and use it. A style guide provides a road map which the developer should follow and implement in coding. So in a group of developers, all the code generated will be of consistent in nature and reusable by any coder\/developer.<\/p>\n 8 Comments<\/strong><\/p>\n Sometimes the code is not all commented and for other cases, it’s over-commented. Maybe you have already read this phrase: Good code is self-documenting.<\/strong><\/em><\/p>\n Yes, it’s a good practice to let the code\u00a0clean to talk for himself and avoid the comments. but in the real world, it’s the not an easy task. In\u00a0some\u00a0cases, you need to clarify what the code does.<\/p>\n 9\u00a0 Coupling<\/strong><\/p>\n Low coupling is desirable because a change in one area of an application will require fewer changes throughout the entire application. In the long run, this could alleviate a lot of time, effort, and cost associated with modifying and adding new features to an application.<\/p>\n Functions using many other functions\u00a0are very difficult to understand and maintain. It\u2019s recommended to minimize the efferent coupling of your functions.<\/p>\n <\/p>\n\n
\n
\n
![\"sqlite6\"](\"http:\/\/www.javadepend.com\/Blog\/wp-content\/uploads\/sqlite6.png\")
<\/a><\/p>\nFunctions should be short and sweet, and do just one thing. They should\r\nfit on one or two screenfuls of text (the ISO\/ANSI screen size is 80x24,\r\nas we all know), and do one thing and do that well.\r\n\r\nThe maximum length of a function is inversely proportional to the\r\ncomplexity and indentation level of that function. So, if you have a\r\nconceptually simple function that is just one long (but simple)\r\ncase-statement, where you have to do lots of small things for a lot of\r\ndifferent cases, it's OK to have a longer function.<\/pre>\n
<\/p>\n<\/a><\/p>\n\n
<\/a><\/p>\n\n