Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Agreed, obviously. :) But you should add a social component and team play to it. From that point of view, "good code" is code most if not all devs in the team can easily work with, code that allows for finding and fixing bugs easily, code that helps implementing new features and delivering value fast. If in doubt I would prefer that approach and let the team come up with "clean code" definitions of its own. Code reuse is a good example: We've seen a load of situations where we started with "reusable" code moved into shared libs rather than (cough) copy-paste'ing a bunch of files around - and found ourselves ending up in considerable library versioning effort. Our solution to that, so far, has been making the team obviously do code reviews for each git pull request and make sure that, asides from being able to build and run code, at least two or three guys on the team accept that code as "clean enough". So far this works quite well. ;)
Yes, code reviewing and having a set of standard patterns for normal use cases is very important to have a clean code base, which is readable and maintainable by anyone in the team.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Agreed, obviously. :) But you should add a social component and team play to it. From that point of view, "good code" is code most if not all devs in the team can easily work with, code that allows for finding and fixing bugs easily, code that helps implementing new features and delivering value fast. If in doubt I would prefer that approach and let the team come up with "clean code" definitions of its own. Code reuse is a good example: We've seen a load of situations where we started with "reusable" code moved into shared libs rather than (cough) copy-paste'ing a bunch of files around - and found ourselves ending up in considerable library versioning effort. Our solution to that, so far, has been making the team obviously do code reviews for each git pull request and make sure that, asides from being able to build and run code, at least two or three guys on the team accept that code as "clean enough". So far this works quite well. ;)
Yes, code reviewing and having a set of standard patterns for normal use cases is very important to have a clean code base, which is readable and maintainable by anyone in the team.