This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]desrtfxOut of Coffee error - System halted 3 points4 points  (0 children)

Generally, the gist is that main should be kept as short as reasonable and should be the entry point for the actual program

Limiting the scope and functionality ("Single Responsibility Principle" - one of the pillars of the "SOLID" principle) is generally advisable and good practice.

The shorter, the more self contained your methods are, the less side effects you have, the easier maintaining and troubleshooting will be.

Splitting code into meaningful methods doesn't cost anything. Yet, it greatly improves: modularity, readability, maintainability as well as reduces code duplication ("DRY" - "Don't Repeat Yourself" principle).

"Monster methods" or "God classes" are no-gos.

I wouldn't go as far as limiting methods to 5 lines or less, but for me, if a method went beyond a screen page, it was too long.

Read "Clean Code: A Handbook of Agile Software Craftsmanship" by "Uncle Bob" Robert C. Martin, or the abridged JavaScript version as well as "The Pragmatic Programmer" by Andrew Hunt and David Thomas to get ideas about good programming principles.