Just finished merging seven scripts into one, but got me thinking that I really don't have a formal logic for breaking scripts into pages, or why I'd merge them.
Suggestions?
-
2Your Handle is ideal for you ;).– RangerMay 20, 2011 at 10:26
-
1There is a difference between putting 7 scripts into one script verses 7 scripts in one file/page.– JeffOMay 20, 2011 at 12:51
-
@Jeff O: True, it was 7 scripts into one script.– blundersMay 20, 2011 at 13:58
-
can you explain the details of your "merging"? did you take out the code duplication, or just concatenated them?– rwongMay 21, 2011 at 9:28
-
1@rwong: I removed large amounts of duplicate code. Main reason I did it though was it was hard to read, if I want I could easily break it apart now that it's cleaned up.– blundersMay 21, 2011 at 12:15
Add a comment
|
7 Answers
Though this is really principle of OOD, I think that the Single-Responsibility Principle can provide guidence here.
A script should do one thing well, and have one reason that it would change.
I can't think why seven scripts would be merged to one, though I can imagine breaking a massive script into more logical pieces, that have a consistent level of abstraction.
answered May 20, 2011 at 10:32
-
15000 rep! I'll have to go and approve a tag wiki edit, or something . . . May 20, 2011 at 14:35
-
Nah, SRP is too easy and thus a dangerous habit. Successfully dealing with a monolithic design is what separates the men from the boys.– JobMay 20, 2011 at 17:10
Well... if you're maintaining files that consist in thousands of lines of unreadable spaghetti code, re-engineering things so that they're split into smaller, logically organized components and files is usually in order.
By contrast, if you've bits and pieces all over the place to the point where a newcomer who is browsing the code source has absolutely no idea of where to look for anything, it might be time to be re-organizing things in a less obscure way and possibly merging a few files.
In addition to using your hunch, I'd suggest this variation of the Mom test.
The Mom test, in case you're unfamiliar, is a simple and extremely practical usability test, which consists in having your Mom use your app for 5-15 minutes with little to no explanations. If she cannot complete a handful of pre-defined and essential tasks, you should head straight back to drawing board.
In its coder iteration, it consists in having a coder friend scan your source code for 5-15 minutes with little to no explanations on how it works, and having him give his best guess at how the code base works (even a vague idea is fine). If he's nauseated after a minute, can't make the slightest sense of it after 15, or comes up with something hideously wrong, you should seriously consider re-organizing your code and adding reasonable amounts of comments in your file headers.
answered May 20, 2011 at 11:09
-
+1 @Denis: Really like the Mom test idea, though that's pretty in depth for just deciding if code should be merged or partitioned. Still like the idea... :-)– blundersMay 20, 2011 at 12:04
-
Splitting things into several files might be a good idea from a source control point of view. Easier to manage and track changes if everyone isnt' working against the same file.
-
+1 @mko: True... :-) though I'm not using source control, and it's only me using the file(s).– blundersMay 20, 2011 at 12:07
Try to explain it to a non-technical person. If you don't have one handy to help you, a dog or cat or cardboard cutout will do almost as well. If you can explain what a piece of code does, without going into a run-on sentence, it's likely to be a good unit itself. If the explanation is far too technical and requires detailed knowledge of another script, it probably needs to be merged. If the explanation uses "and" a lot, it probably needs to be broken up.
answered May 20, 2011 at 15:54
The logical reason to have kept those seven scripts apart was so you could've spent that time outdoors. Wait! It's not too late to do that anyway!
As seven individual scripts, the single purpose of each script becomes blatantly obvious. With any luck, each of those scripts is now reusable wherever the need for that single purpose arises. Plug it in anytime you need it and go kayaking with the extra time you have.
On the other hand, the purpose of the single script is blurred because it now performs seven tasks. Imagine if next time you merge 25 scripts, or 100 scripts into one Mecha-Streisand of a script? Are you gonna remember that the single purpose you require now resides somewhere in that huge script? Of course not. You'll just wind up writing that functionality over again in another script and miss your chance to go, oh I don't know... let's say spelunking. =P
As a whole, 1 class per file is a reasonable idea, it means if you have to blow it away for a better idea you had, you only take out one file, if its intermingled with other code, chances are you could miss something.
My rule of thumb is if its a quick hack to do a short dirty job, go with 1 big file of doom, if theres even the remotest chance you're going to be coming back to it, split it out, so you can forget everything, but then find everything later.
-
Corollary to rule of thumb; sooner or later you always come back to the code.– Jim CMay 20, 2011 at 12:12
Strongly recommend this book on refactoring. It talks about your specific case as well as many other very common "patterns" of code that needs to be changed.
In general they advise, and I always followed the same philosophy, that you should break methods/classes/files into many files if that increases clarity, readability and maintainability of your code. And you should combine individual methods/classes/files into one if that increases clarity, readability and maintainability of your code.
