Recently, I read an Article where the author, Jerry Low, suggested that developers write their CSS properties in alphabetical order. I think this is a great idea, and it got me thinking what some other tips for writing clean and readable code? Feel free to share your suggestions.
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (31)
My advise would be to ask the following two questions repeatedly after you are 'done' writing your code:
If you repeat this often enough you will get to a point where these steps would remove and add the same piece of code. Stop at the more readable version.
The great thing about this cycle is that it scales with your experience and is applicable to all programming languages.
التكثيف من كتابة التعليمات البرمجة لتسهيل مهمه الباحث المهتم لعلم البرمجيات
واتمنى ان تكون الخيارات حاضرة لمساعدة المبتدئين في علم البرمجة شكرا لكم
hmm.. I don't like that approach. I've never tried it but I feel like that would slow me down. I preffer modular and small css files. Another thing I like doing is using the
idattribute to distinguish the different sections. So I can write styles like so#info_card .titlewhich makes it easier to find the section I need to work in.To me, a clean code rule has to be something that is worth the effort in the end.
I'm not that fast at alphabetical sorting, so I would take a lot of extra time and it would exceed the benefits it could provide.
My favourite type of sorting is the one my IDE does on autoformat.
I have a simple, modest suggestion: Almost every programming ecosystem has tools (pretty-printers, code formatters, or code beautifiers, depending on how old your language is...) to enforce a style. Just do what they say for new code, instead of arguing about style. Don't like that style? Use the same tool, configured to whatever style that you would prefer to look at.
Seriously, after sixty years of code, we need to stop wasting time arguing over style preferences. Let
cb,prettier,gofmt,rustfmt, or whatever do that thinking. The format doesn't matter, as long as everybody commits to the same standard. An exception, as hinted above: Leave the pre-beautifier code alone, until you need to change it. Nobody needs a ticket to automatically fix the indentation on a million lines of code written before they were born...And then the time saved on arguing about format can go to fixing all the warnings that the linter keeps complaining about that you either don't know about because you're not running your linter, or have been ignoring because "it's only a warning."
Try to create a function with a readable name whenever you want to better describe a piece of logic on your code.
Also try to bring together code that are "speaking" about the same topic.
If you struggle in doing the above, write some comment to describe the code. I don't think 100% that the code should be self-documented, but I believe that we should try our best to avoid comments :)
Writing CSS properties in alphabetical order? I fail to see how this can make the code clearer; maybe it helps when you are searching for a property, but Ctrl-F (or Ctrl-s if you are an emacsian) works fine too.
To me "clean code" means code that makes it easier to understand what its goal is and how it achieves it. In this respect, I find that using meaningful names for variables, functions, etc. helps a lot. Using some comment to explain the goal of the function, module, etc, and the "conceptual model" behind it helps a lot too (and this is a kind of comment that is unlikely to get stale, since it is related to the overall architecture). Comments explain the algorithm can be helpful if the algorithm is not trivial and/or to explain some choices that seem strange at first sight (e.g., "We use this structure instead of the more obvious ... because later we need to ...")
To me, it's usually a triangle: Efficiency, readability, abstraction.
However, it's rarely the same distribution, as it can vary from one project to another, depending on the context. I can't give a general rule but this how I see the project in terms of clean code.
You can't neglect performances but you have to avoid micro-optimization, especially when the code becomes too "ninja", a.k.a. less readable and maintainable. If you're the only one who can modify the script, it can become a problem quickly.
Too much abstraction is not really good in my experience. It can jam code reviews significantly. Besides, you can get a lot of unwanted side effects, so more stress for maintenance, etc.
Imagine while coding the colleague who has to maintain the code after you is a violent psychopath who knows where you live. 😅
wow, "no method must be greater than 5/10 lines".. So, basically most complex methods will be composed of methods only? I can imagine a class having 20 more methods because of this rule 🤔. It is true that one method shouldn't have too many lines, but going the very opposite of 5 lines is just too extreme.
I can agree on the "no more than 4 parameters in a method" rule. This makes more sense than the extreme methods lines limit rule.
I can rescue and agree with you totally on what you say at the end: Focus on making smaller methods and the rest will follow.