tag:blogger.com,1999:blog-5028009537158799436.post1661344273823454778..comments2023-07-10T04:50:03.236-07:00Comments on Building Real Software: Rule of 30 – When is a method, class or subsystem too big? Jim Birdhttp://www.blogger.com/profile/17371102366836131341noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-5028009537158799436.post-42018646256426765392018-04-02T10:13:45.100-07:002018-04-02T10:13:45.100-07:00@AndD: you could try just about anything to break ...@AndD: you could try just about anything to break that class out. Whatever you do will help make the problem simpler. Start doing it now.Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-7040316040509358042018-03-28T22:39:38.592-07:002018-03-28T22:39:38.592-07:00What approach i should follow to refactor my class...What approach i should follow to refactor my class if it already have 40,000 lines of code and i need to add moreAndDhttps://www.blogger.com/profile/10385225962819855239noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-30534192777631828542015-08-10T16:21:03.633-07:002015-08-10T16:21:03.633-07:00I call it the 10/100 rule.
Methods shouldn't ...I call it the 10/100 rule.<br /><br />Methods shouldn't be more than 10 lines of code.<br />Classes shouldn't more than 100 lines of code.<br /><br />It isn't just based on "opinion" it is based on the result of a decade of practice. It is also based on the fact that common engineering design patterns automatically appear and are automatically used appropriately when following this rule.<br /><br />Feel free to read more about it here:<br />http://www.rhyous.com/2014/02/10/the-10100-rule-following-this-one-development-rule-will-improve-your-code/Rhyoushttps://www.blogger.com/profile/12742079863966463589noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-13847950737161578542014-08-28T02:22:51.656-07:002014-08-28T02:22:51.656-07:00I am looking at a javascript file(one among many i...I am looking at a javascript file(one among many in the project) developed by someone else. This file has 10K plus lines and 823 methods. The next one I am working on has 12K plus lines and 471 methods. And there is a related java file that has 2 core methods that each run to 300 plus lines - this java file runs to 6K plus lines. There is no time to refactor. I need to just make changes to existing code for the feature I am developing. What can I do?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-54789493742623972812013-09-11T10:42:49.148-07:002013-09-11T10:42:49.148-07:00@Rob greene,
Brilliant. I like your suggested new...@Rob greene,<br /><br />Brilliant. I like your suggested new rule of 30 seconds :-)<br /><br />Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-17624715510389826202013-09-11T10:22:12.364-07:002013-09-11T10:22:12.364-07:00How about a rule:
A method must be understandab...How about a rule: <br /><br /><b><br />A method must be understandable to a developer reviewing it within 30 seconds. <br /></b><br /><br />It should take less than 30 seconds for a developer to understand what a method is doing, even if the methods it calls are not understood. <br /><br />Anonymoushttps://www.blogger.com/profile/12100187732639281214noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-27699205092611236662013-02-14T23:47:13.415-08:002013-02-14T23:47:13.415-08:00If you follow the paradigm "code is comment&q...If you follow the paradigm "code is comment" Smaller methods with names that describe the intent of the method will make the experience of the person who come to visit your code richer.. and eventually u will end up with a lot of reusable methods as well as easily unit testable.. Through smaller methods some fixed contracts will emerge which never will have to be changed when the code evolves as long as the requirement doesn't drastically change.. just my 2 cents..Soney Mathewnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-80913362782496560372012-12-13T06:46:27.976-08:002012-12-13T06:46:27.976-08:00@earcam, Good point - large classes and methods te...@earcam, Good point - large classes and methods tend to get larger, so you are putting yourself at more risk of having the code get out of control. If you start off small, it would be difficult to get into this kind of trouble.<br /><br />Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-24107384885858330342012-12-12T05:16:23.122-08:002012-12-12T05:16:23.122-08:00As always nice post, very succinct, thanks Jim =)
...As always nice post, very succinct, thanks Jim =)<br /><br />I'm with Robert Martin's smaller is better. One thing he discusses is mixed levels of abstraction - following this I rarely have methods longer that ten lines.<br /><br />While it may smell like you're desperate to <i>do functional</i>, you end up building internal DSLs and discover a surprising amount of reuse at this low level.<br /><br />Keep it small and let your compiler do the inlining (or VM JIT-ing, etc).<br /><br />On a similar vein, a recent Micheal Feathers post discusses Behavioural Economics wrt Code; adding new methods vs adding code to existing methods and the same for classes (addition or extension).<br /><br />Large methods/classes will only get larger, unless somebody takes the conscious decision to refactor.earcamhttps://www.blogger.com/profile/00745957800443401442noreply@blogger.com