re: What programming best practice do you disagree with? VIEW POST


I question anything too religious around small files and tiny methods. Sometimes the better choice is to toss another method in the class so it’s easy to find rather than stash it away elsewhere in the codebase.


My counter to this is that with any suitably large product, having a logical folder structure that you religiously stick to, regardless of file size/content† , you can reliably find the content that you are looking for. Okay you occasionally deal with a silly file, but its better than having someone recreate something and have inconsistency between what should be functionally identical.

For small/informal project then I understand the convenience, but otherwise i feel it can add to problems long-term, especially when working with big/multiple teams.

have a single exported const in a file for all I care


I would add that the weird stigma against having one really long function doesn't make much sense to me. It's totally fine to have a really long function if nothing else uses what is inside of that function (say something that gets run once on launch to setup all of your Analytics trackers).


Great example! Code that abstracts away "TrackerInitializers" and then lets an array of trackers attach themselves and initialize and ... suddenly we've got code that's theoretically pure for no good reason and requires a good bit of reading to figure out what it actually does. When it's time for something to change, it's a copy and paste 2 years down the road, and the new paste may not even fit into the interfaces we've built...


I think modern IDEs are pretty smart to walk you to the file/class which encaosulates the method.
For me the method length limit is imposed by the response to simple question - "What the method accomplishes?". If you are not able to answer without using AND ..this.. AND ..that. AND ... multiple times, then it is time to better encapsulate the logic and maybe change the project's design.

code of conduct - report abuse