I still don't know a valid answer to that question, not because I disagree with the answer given here.
To me at least they're not new at all, the ruby part is to emotional for my taste but that's just the classic ruby approach (which is okay but I want to have metrics not pathos)
the clean code book is a classic move, I was waiting for someone to mention smalltalk.
sergio and others do have a pragmatic approach I do appreciate, celox wrote one of the classic quotes
maybe someone should bring up the wtfs per minute measurement? it's missing.
My thoughts to the question, I will go for the semantics of the words and less to their implementations.
Style is easy. it defines a certain way to do things. So this is about procedure and structure. There we can use our best practices. as long as we can stay consistent and can explain how things are built and used it's rather easy.
Elegance is a composition of meanings containing (i take the webster scientific definition here)
This is a complex topic, it's always interesting to read about it most of the time the same answers appear. There is no definitive answer it's like the agile manifest .... the manifest is really good the implementations of it tend to get religious and loose a lot of meaning.
In the end thx for the question and to all for sharing your thoughts.
From my point of view : Write code that you or your team can understand now & later.
However, Coding the product to make it works is the first point that you should care more about. After that you can go for refactoring the code lines.
Extremely a lot!!!
Specify some rules and stick to them as a team. You should establish a development environment by using some standards (for example in js development):
These will make code reviews faster and the whole codebase will become much more maintainable. It will look like as if the same guy (you) wrote all of this code. That way everyone will feel extremely familiar and comfortable with it. Refactoring cycles will last less and your team's level will improve much faster.
Also consider that a messy codebase will make you frustrated every morning you open your computer. This is counter-productive and you 'll lose much time fixing ugly things here and there in random. If you think some more about it, you are wasting your time because you may beautify a file today and a teammate will probably break it again by overriding your fixes. This includes simple things like indentation and quite complicated like ES7+ features implementation. Common rules are really important so you avoid doing circles over and over again!!
As a developer many times your bosses will push you to make things faster and faster. Unfortunately, this is true since many product / project managers don't care about the codebase itself or they don't have any programming experience so they are focused only on revenue etc If you are forced to take shortcuts again and again by lowering your standards, find a better working environment and walk away. Sooner or later this wrong mindset will harm you and this project a lot.
Always code as if the person who will maintain your code is a maniac serial killer that knows where you live.
When you are working on a commercial project chances are that you might have to develop some parts of it as a team and someone else might have to maintain your code once you are assigned to the next one.
Keeping the best interests of your team and future maintainers in mind always follow best coding guidelines and practices for a particular language, specify the purpose of each component at the top, input parameters each function takes,its expected output and purpose in comments.
The simplest things to follow are writing code that is easily understood rather than trying to obfuscate the code just to show off, assigning names to variables/objects/functions which are easily to reflect the purpose of defining them and indenting/linting the code.
Writing elegant code would also mean trying to optimize and refactor the existing codebase for performance improvements but we should generally try to do such optimizations towards the end since trying to optimize right from the beginning might slow down the development cycle.
How much professional would you like to look like? The same answer applies to both questions :)
I struggle to express this importance to my students. I suspect code elegance and style is too abstract until you've faced bad circumstances with heavily unorganized code.
Use new language features, best practices, coding standards in teams and refactor 3-4x - small simple extendable code base - the result is elegance & style
Very much !
The Rails doctrine summarises it much better than I ever could:
Exalt beautiful code
We write code not just to be understood by the computer or other programmers, but to bask in the warm glow of beauty. Aesthetically pleasing code is a value unto itself and should be pursued with vigor. That doesn’t mean that beautiful code always trumps other concerns, but it should have a full seat at the table of priorities.
If you ever want to work in a team, use source control or ever go back to code you've previously written it's important. Use descriptive naming and comments if things are difficult to explain.
However, make it work first, then worry about optimising it :).
/* no comment */
Quique Borredá
Passionate about web since 1991
I read this one somewhere and has stuck with me ever since
"The code produced from a team should be appearing as if it has only been written by one person" .. set your linting strategy early and always try to enforce it.