Just make things work in a simple fashion.ĭevelopers don't want to document code, (I love documented code personally, I'm not that selfish). Until we get a bug and wish we were writing "Cat in the Hat". Our goal with code should be to write 300 lines of clean code.Īs developers, we want to write "Lord of The Rings". Searching through 10000 lines assembly is harder than 10000 lines of python, if it is done correctly.īut some work requires writing 500 to 1000 lines. Most of us are not writing assembly code. This way our code can speak more volumes than what we see written. Utilizing and creating libraries to enhance functionality and code reusability as much as possible. Cyclomatic Complexity is an important concept that may developers should consider as they generate code. To my point, writing code should make sense to a 5 year old whenever we can. Both can be understood by a 5 year olds, but only one is better suited due to content. There is nothing wrong with Lord of the Rings. When it comes to code length, I think we should consider the following: The Cat in The Hat (50 pp.) a 300 line method body that spans six screens, or a source file with 5000 lines of code).Ĭonsider this Metaphor. Also, as Martin Beckett suggested, there are situations in which a class is a large collection of methods and it does not make sense to split them in some artificial way just to make the class smaller.Īnyway, in my experience a file starts to get unreadable when one of the above parameters is not respected (e.g. This is really a very rough estimate and I do not follow these criteria systematically (especially because there is not always enough time to do proper refactoring). So a source file that is more than 2000 lines is probably too large and starting to be too messy. Putting together these very rough estimates: If you introduce too many private help methods you can consider creating a separate class to collect them (if you have more private methods than public ones, maybe a second class is hiding inside your main class). So, if you have to scroll more than one screen up or down to read the whole method body, your method is probably too big and you can easily lose the overview.Īgain, splitting methods using private help methods can reduce method complexity very fast (at every split the complexity is at least halved). If this is not the case, you only need to scroll up and down a bit, without forgetting the part of the method that gets hidden. Ideally, you can see the whole method in one window. Splitting is a very effective method because every time you split a class you reduce the complexity of each individual class at least by a factor of 2.Ī method body that does not fit in one or two screens is too big (I assume that a screen / editor window is about 50 lines). A class that has more than 10 method is probably too complex and you should try to split it. Therefore: each class should not have more than 7-10 methods. Above 7 we find it difficult to keep an overview of what we see. Seven is considered the number of items that our brain can observe at the same time without getting confused. One class per file (in C++: one class -> one header and one implementation file). to think in terms of logical structure and not in terms of lines of code): As an ideal model I use the following criteria (with a similar rationale to what Martin Beckett suggested, i.e.
0 Comments
Leave a Reply. |