C
First to be objective I have to suggest something subjective.TeamworkYou say "facilitate whoever moves the code later." That "who" is very important. As much as you have a correct way of dealing with the subject technically one aspect cannot be left aside. Politically you have to take into consideration specifically who's that who.Following what your team expects in many cases is more important than following rules, especially the blind rules. How do you expect a code to be easy to maintain if everyone who will likely mess with it does not expect and possibly do not understand what you wrote, however much it is correct?It gets worse if you don't even know who these people are, i.e. when you're thinking about future programmers replace you with software development.Functional style X imperative styleLooking at your code, it has a problem for most programmers. I would kick that 90% of the programmers who might come to give maintenance in their software do not understand the functional programming style well. Even those who understand the use of collection extension methods for queries do not fully understand their implications (lazy evaluation and side effects for example). And what will happen when that programmer moves your code? He'll probably leave yours and write his own version.You can argue that is programmer's obligation to know how to use all language resources. And I'd be with you on that one. I have even resigned a job because I was forced to make such simplistic codes for the most beginner in programming. I wasn't politically correct, I just made a choice for my life.O common programmer understands better the imperative style, he understands how loop works. It is no use saying that your code is obviously taking 9 elements from a collection and applying a formula to each of these elements and adding all the results. It's obvious to me how this works, but it's not for a lot of people. Perhaps the programmer can even understand, but does not know how to change this to achieve a different result that maintenance requires. We realize this happening here in this very same Website all the time.And imagine in a more complex example. Your example is simple and is not so difficult to understand. I'm considering that it's just a straightforward example posted like that, but the problem will actually appear in more complicated situations.In some cases it can be tricky to make the functional style properly since we do not always know the implementation. In imperative style an inefficiency would be more obvious.I know this example does not need performance, but the programmer will have difficulty improving more complex codes by not fully understanding what is happening in the code.The internThen I will answer you that depending on the possible scenario of those who will maintain this code is difficult to maintain because it uses resources that few people are familiar enough.I myself would not follow this rule of the minimum common denominator, but this is my decision and I am willing to deal with the consequences of it.Variable namesMaking a specific analysis in your code (only in the most important parts), I say that their variables use good names.Yes, variables must have significant names. And yours do. Why? auxiliar is more readable than aux or because primeiroDigitoVerificador is better than dv1? (I used tiny simply because this is the convention adopted in language)Who said use contadorDasVezesQueAlgumaCoisaOcorreEmUmLaço is better than i. Too long? I did what the rules! But even if I use only contador he does not help understanding more than i in one loop.Of course. the further away from your statement a variable will be used, the more the name needs to be significant. But when it will only be used in a limited scope, the name is not so important. Of course, don't use random names (I knew a programmer who used swearing in all variables). You did good.Using a name with meaning can be useful to give semantics to a passage of code and https://pt.stackoverflow.com/a/15566/101 But that's not always so important. Comments should be avoided, but it has to analyze the context, is more wrong follow a rule blindly.It is not curious that practically every example of code teaching lick uses x as an argument? Examples written by programming geniuses! Do they not know the books that say the variables should have significant names? Or do they just know how to use the rule properly and not blindly?If you are going to analyze well, in your example if the argument was called elemento or item would be more descriptive, but everyone uses x and no one who knows the mechanism used ceases to understand that there is an element of the collection.The lesson here is to be careful with established rules. Whether they are spoken by strangers on the internet or by consecrated computer authors.Even the best more popular books have been written in contexts that most people don't know, they are often vague when something should be used (and it has to be, there are so many scenarios) and do not usually explain how it came to that conclusion (when it explains, it does not emphasize this, emphasizes the simplified rule that everyone will keep). Then a book that seems very good and well-intentioned ends, by failure of readers, leading people to commit barbarities, where the intention was opposite. And worse, almost no one realizes happening. They start using the book as a crutch for their atrocities. https://pt.stackoverflow.com/q/120931/101 For me, one of the most important principles in coding is the https://pt.wikipedia.org/wiki/Don%27t_repeat_yourself . He preaches that, simplifiedly, codes should not be repeated.In your code there is repetition. A stretch can be abstracted in a function and eliminate repetition.When you have code repetition, it's harder to maintain. The change at one point does not guarantee that the other point is changed in the same way.Of course the chances of error in the posted example are not great. But they exist.This is similar to the comment problem. The comment is common to be repetition, even when it does not appear to be. When you change a code and do not change the comment to reflect the change, potentially you may have a dissonance. Remember that this is not a rule, I am not saying you should not use comment.Note that abstracting depending on the repeated code in question will not make the code more concise, but will make it have its unique representation. https://pt.stackoverflow.com/q/120931/101 . Concision does not always help maintenance, having a unique point to change an algorithm helps maintenance. Since creating this abstraction is no longer complicated than leaving the code inline.I even admit I'm overreacting at the DRY, but ignoring it has always brought me more maintenance problems.Also do not follow the DRY blindly.Tips(not rules)ask others to analyze your code;try to understand your old programs;try to read your code without the help of editors who "feel" the code;know all coding rules and learn how No use them (how to use it is easy).ReferencesSome of the books that talk about most are https://books.google.com.br/books/about/Clean_Code.html?id=dwSfGQAACAAJ and https://www.cc2e.com/Default.aspx . The Portuguese version is not so good.I have reluctant to put them because they are a little dogmatic, try to sell ideas that do not work so well in all situations, sell ideas that seem absolute when they are not, and can create a trend for those who are not experienced and think the book works as a manual. If you do not know how to use Tips that books give, risks becoming dogmatic too.The first sees a very specific way of developing, it practically requires choosing certain tools (not software but paradigms, methodologies and techniques) for everything. If you know take only what is most important to apply to yours situations can take advantage of your content.The second is a little wider in the considerations but tries to be too specific in some cases and does not contextualize well. It is common to give tips that work well in one language and not in another, but it does not handle it.Final remarksYou still have a legibility problem for other factors, mainly because of the ternary (I love this operator) it was hard to read the code. It seems that you were so happy that you managed to do everything on a line that forgot the readability. Or not, after all you are here asking her:)Keeping many code lines can affect maintenance as well. Well-thought, non-artificial condition, is good too. You just can't overreact.Not always when a person cannot understand his code means he is unreadable, may be that you are dealing with a "parachutist", increasingly common in our midst.I put some nomenclature conventions https://pt.stackoverflow.com/a/32665/101 .And I try https://pt.stackoverflow.com/a/33726/101 . And https://pt.stackoverflow.com/q/173216/101 .
