"but not the best possible practice"

And you of course know what the best possible practice is. On a side note you might want to look up the dunning kruger effect.

There are best practices... and there are best practices.

I will call technicalEngineering best practices.

Like alwaysAlways use library methods instead of making your own. Don't reinvent the wheel etc...

None of which are followed in CS classes because you want students to learn how to write a bubble sort, quicksort, merge sort, binary tree, etc... because the experience of building those algorithms makes for a better programmer.

style best practices

Such as using descriptive names for variables, and methods. And not using magic numbers... And yes const int FIVE = 5; is still a magic number. where as const int WEEK_WORK_DAYS = 5 is not a magic number. Because FIVE doesn't have a meaning attached to it.

Some of those don't really matter such as:

• Spaces instead of tabs (unless you think tabs are better, in which case Die Heretic Scum).
• Or how to place curly brackets.
• The number of spaces in an indent (3,4... just be consistent).
• snake_case vs camelCase vs CamelCase (again just be consistent).
• This list is really long...

The biggest style best practice is of course what your customer IE the professor tells you to do. As long as your code is readible and maintainable...

The customer is "always right on matters of style" after all

There are good design practices, or perhaps best known method:

I would read stuff by Robert C. Martin for a better answer then I want to put in a here... But basically it boils down to decouple your stuff. Write unit tests where possible. Write integration tests. Write functional tests. Don't have code behavior rely on hidden state (avoid global variables) if at all possible... Etc.

Use design patterns that make sense for the problem you are solving. E.G. don't hammer in screws.