3 ms·

The problem isn't "best practice" per se, it's "best practice" in practice. :) I can see good use cases for OOP, for instance, but OOP's definitely a leading c

The problem isn't "best practice" per se, it's "best practice" in practice. :) I can see good use cases for OOP, for instance, but OOP's definitely a leading contender for the "over-engineering" trap. I've certainly seen my share of "OOP / pattern spaghetti" to the point where just coding a simple select call involves writing several classes in random locations in the project. Like goto spaghetti, the result is way harder to debug and maintain. I personally think lower level advice like DRY is much more important overall than patterns (in many OOP projects, it seems, I feel like they violate the KISS principle for no real benefit). Even naming conventions can fall in this trap. Consistent naming convention is absolutely a great idea. And then you run into the database that have several naming conventions, all inconsistently applied depending on the state of the project at the time. I've found inconsistent naming conventions not much more useful than no naming convention at all.

Benjammer 10y ago
>I've found inconsistent naming conventions not much more useful than no naming convention at all. Try working with someone who's idea of expanding the app is literally taking a controller class for another page that does something vaguely related to the new feature, copy-pasting it into a new file, changing the class name (like put an "N" at the end of it like "SearchResultsView"-->"SearchResultsViewN"), and then changing some of the internal business logic without changing the names of any methods or variables. What you're left with is something that is much, much worse than no naming conventions at all. It's actually naming conventions that actively mislead you as to their scope and function. Like a "clickedEditButton()" method that is actually wired up to a "back" button on the page and takes you back to the previous screen.

Benjammer 10y ago

>I've found inconsistent naming conventions not much more useful than no naming convention at all. Try working with someone who's idea of expanding the app is literally taking a controller class for another page that does something vaguely related to the new feature, copy-pasting it into a new file, changing the class name (like put an "N" at the end of it like "SearchResultsView"-->"SearchResultsViewN"), and then changing some of the internal business logic without changing the names of any methods or variables. What you're left with is something that is much, much worse than no naming conventions at all. It's actually naming conventions that actively mislead you as to their scope and function. Like a "clickedEditButton()" method that is actually wired up to a "back" button on the page and takes you back to the previous screen.