best practice discussion

[broken marsh]

.starting thread message

[ruby crag]

https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview?tabs=net-7

IDEs can enforce style, all sorts of things can measure code quality

there's a load of non-subjective metrics that you can choose to use

some teams make all warnings into errors so you're forced to write code to their standards

[broken marsh]

if we arent talking about performance, then code quality is subjective yes, which is why there are guidelines. Each team can apply whatever styles they want and you will quickly be fired for not following them.
For example: regions. Most people I talk to hate them, but if your team uses them, then so do you.

[bold raptor]

you should be able to look at code and understand what it does fairly quickly

[zinc sorrel]

Depends on the team and company. Tbh.

[stoic flame]

You can say it depends for every problem, that does not add value

[ruby crag]

Even outside of just straight up style, code quality has all sorts of other metrics some people use, like cyclomatic complexity

[zinc sorrel]

thats what i've been saying this entire time though. You say theres "Best Practices" that you should always follow.

im saying it really depends on the problem you are trying to solve. Some of the better solutions can be directly opposed to these "best practices".

[broken marsh]

Whats said about best practices vs whats done in reality will obviously differ, but the goal is to aim for the best practice. If you aim for best practice and fall short, hey at least you're in decent practice.
If you aim for shit and fall short, your company fails

[stoic flame]

All serious companies/teams have their standards

[ruby crag]

And most of them will have at least looked at the standards in the ecosystem instead of just making up their own because they felt like it

[zinc sorrel]

well obviously u dont just make one up, but u dont write code just because its the "best practice" you need to back up your shit with logic

[broken marsh]

Some of the better solutions can be directly opposed to these "best practices"
care to elaborate on that? Because this makes no sense

solution to what

[ruby crag]

Sometimes the logic is just "write the code to the standard because having standards is better than not having one"

[zinc sorrel]

sure, but you shouldnt be religiously following the standard as if its the bible

it should be a guideline, and you should know when to break it

because theres some solutions that dont follow the "best practices" but are still a better and more maintainable solution

[ruby crag]

Code standards guidelines should be specific enough that you don't really need to break them. Actual implementation is not that though

[broken marsh]

I have no clue what you mean by that. it sounds like you are talking about making a quick working solution vs taking the time to set it up to be expandable.

I do say that not every single thing needs to be modular/expandable/any other corporate jargon, but you are saying theres a solution better than what the best practice would provide. The best practice doesnt limit you from implementing the exact same algorithms

[ruby crag]

Some people swear by SOLID or whatever and you can sit over here with me having never learned it or caring about what the blah blah substitution principle is about, and yet you should still make a project not mix up naming conventions unless you're in the middle of a transition

[zinc sorrel]

basically... when you encounter a scenario where theres an easy to read and write solution that does not follow the group approved "practice" and if you were to follow these "best practices" guideline the problem becomes stupidly convoluted

[stoic flame]

I can see you advocating static 😄

[broken marsh]

Some people definitely do go overboard, like the example of enterprise fizzbuzz is a great one

even though its clearly meant to be a mockery, its still a good example of how easy it is to go overboard

[ruby crag]

Implementation practices get stricter the more an API is exposed to users imo. If you're doing something that is in a small area of the codebase solving an internal problem, who cares. But if you're exposing that stuff to users (including other programmers in your team) then you should consider being proper about it.
Though, even that depends on what sort of team you're working in. Things out of games will often have a lot stricter practices

private/internal static, probably ok. Public static... I'm giving you the eyes and looking at what you've done