Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
Your Handle is ideal for you ;). –  Ranger May 20 '11 at 10:26
1  
+1 @Ranger: Yes, I know, thanks! :-) –  blunders May 20 '11 at 11:58
1  
There is a difference between putting 7 scripts into one script verses 7 scripts in one file/page. –  JeffO May 20 '11 at 12:51
    
@Jeff O: True, it was 7 scripts into one script. –  blunders May 20 '11 at 13:58
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. –  blunders May 21 '11 at 12:15
show 1 more comment

7 Answers

up vote 14 down vote accepted

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.

share|improve this answer
    
+1 @FarmBoy: Concise, to the point answer. –  blunders May 20 '11 at 12:17
1  
5000 rep! I'll have to go and approve a tag wiki edit, or something . . . –  Eric Wilson May 20 '11 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. –  Job May 20 '11 at 17:10
add comment

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.

share|improve this answer
    
+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... :-) –  blunders May 20 '11 at 12:04
    
lol, I really like those examples. –  TheLQ May 21 '11 at 3:07
add comment

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.

share|improve this answer
    
+1 @mko: True... :-) though I'm not using source control, and it's only me using the file(s). –  blunders May 20 '11 at 12:07
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
    
Corollary to rule of thumb; sooner or later you always come back to the code. –  Jim C May 20 '11 at 12:12
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.