current community

your communities

more stack exchange communities

Stack Exchange
tour help
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.
up vote 6 down vote favorite
1

This question already has an answer here:

I have noticed that my classmates write unstructured code with a lot of duplication. And their solutions of the same tasks often contains more then three times more lines than my project. But when after completion of the task tutor add new unexpected request I have to spend four times more time in comparison with they. (Example of request changing: we have developed an offline chess, and after that we get request turn it work through the network.)

So I began to doubt if code using "recommended" styles and patterns is less modifiable. Is the code duplication more corresponding for situation with a high probability of unexpected requirements changing?

share|improve this question

marked as duplicate by gnat, Ozz, MichaelT, GlenH7, Glenn Nelson Dec 13 '13 at 14:20

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
2  
Of course it's quicker. They just copy/paste some code than modify it a bit. This is quicker/easier for a school project but the extra effort you put in will reward you. In a learning process i'd say it worth it... but in really you might not alway have the time to make the code a beauty. IMO your way make me think you might be more avanced than those mate. –  im_a_noob Dec 10 '13 at 12:27
1  
"Smart" != "Having Good Memory". Making mental aliases will only get you this (and it's a short "this") far:"ok, the code that does X is found in locations L1, L2 and L3, except that in L3 it also contains validation, so if I want to make modification M1 to it I must only do it in L1 and L2, but if I want to do modification M2 I'll have to do it in L1, L2 and L3, with the extra addendum of A1 for L3 to avoid validation breaking)" . How many of these do you think there are in a project composed of 10 modules, containing thousands of units of code and hundreds of thousands of lines of code. –  Shivan Dragon Dec 10 '13 at 12:56
1  
If it takes you a little more time then I wouldn't be surprised, but 4 times the time??? It makes me wonder if your design may be less lines of code but is instead highly coupled/poorly partitioned. Adding networking to offline chess shouldn't have affected your chess game at all. Other than the main application setup, your code should have easily followed the open-closed principle as it should have been simply a matter of replacing local player with network player, no changes to the chess game itself. If your design didn't do that then I suspect your design is to coupled/poorly segregated. –  Dunk Dec 10 '13 at 14:53
    
Dunk, maybe cause of SUCH difference are their higher intellect (speed of the mind) and my using YAGNI during implementation first requirements. And I didn't mention that we had to develop that project using ECMAScript, though our main languages are C++/C#. –  SerG Dec 10 '13 at 15:23
1  
When you struggle you are learning. Your current approach will help you develop a skill where you are doing both "recommended programming" and preparing the code for future modifications (and I bet that is recommended too). Also, don't be a zealot about the "recommended styles". The book "The Pragmatic Programmer" is always worth a read. –  Robert Jørgensgaard Engdahl Dec 10 '13 at 21:50

4 Answers 4

up vote 10 down vote accepted

This has IMHO nothing (or at least: not much) to do with size of the program. In theory, having less duplicated code should make changes to a program easier, not harder, regardless to the program size. In practice, people sometimes seem to struggle with that, because when refactoring duplicate code out to a separate function or class or library they introcude additional dependencies into the code. And when the next requirement arises, you now have to change things in the in the out-refactored parts, which may introduce unwanted side effects in all parts which depend on that.

To my experience, this only happens if one did the refactoring somewhat wrong before. Just doing a lot of refactoring does not guarantee you a good design. Refactoring things out just because they "look similar" can sometimes make your program more complicated. A typical beginners error here is the wrong use of inheritance, adding an additional base class to a bunch of classes because of the false believe "that's the OOP way of reusing things". And its interesting that your original question title mentioned "OOP", but your question itself contained nothing OOP related (avoidance of code repetition is in no way OOP specific), so I guess this might be one of the problems in your code as well.

So what's the right way of refactoring, which will increase the evolvability of your programs? Unfortunately, that's not easy to explain in a few sentences. Start with these things:

  • defines clear responsibilities for your functions/classes/components, especially the ones created by refactoring. Be nitty about the names you choose for those components, make sure you know exactly the purpose of each component. Then you can handle future changes much, much better.
  • learn why (and when) to favor "composition over inheritance"
  • learn about SOLID
  • sketch the data flow between you components, especially when a new requirement arises, and pinpoint the parts where you will have to change things. This will help you to keep the structure clean and to handle dependencies better.
  • and give yourself some time to learn. Evolvable program design is nothing you learn in a week or two, this takes years.
share|improve this answer
up vote 15 down vote

No, it's absolutely not more appropriate.

Duplication works fine as long as you are able to fit your entire program into your head at once; whenever a requirement changes, you know exactly what to do and where to copy stuff from for reuse.

But that is only true for small programs. No one makes a living writing small programs, particularly not writing programs as small as those you see in school. In professional settings, the programs you have to change are three to five orders of magnitude larger than homework problems. At that level, no one can remember what else there is in a program, where you put those three similar move-generating routines, whether you already coded the helper method you need or not, etc.

This is why "Don't repeat yourself" is so important in practice. As long as there is one place in your system responsible for one task, you have a chance of remembering where it is. If you have three, you may or may not find the correct one, or you may think you changed the right line of code but actually change behaviour in some subtle different way. That way madness lies. The fact that this dynamic cannot be observed with the size of program for which there is time in a standard lecture is the curse of teaching programming, and (personal opinion following) one of the reasons why so many beginners completely fail.

share|improve this answer
1  
It's not just a matter of size of the codebase, also the number of people working on the project. Added to which, these people come and go –  Konrad Morawski Dec 10 '13 at 11:14
    
I supposed that duplication is appropriate only for small project, but I have faced a similar problem on my work, where I develop some project (started without me). I had made some refactoring for reducing duplication in the sources and now I need add new functions and it seems that it would be easier without my previous refactoring. Though it's also not really big project. –  SerG Dec 10 '13 at 11:24
4  
This is tough to answer with out examples. However, it sounds like you might not be adhering to the Single Responsibility Principle. In other words your code may be DRY, but tightly coupled. Tightly coupled code is hard to adapt to changing requirements, even if it is quite DRY. –  forforf Dec 10 '13 at 12:35
    
The explanation of the DRY principle is fine in this answer, but honestly, I don't buy this "program size" thing. If it is easy to extend a small program though some code duplication, it should be easier to modify an even smaller program after the removal of duplicate code. –  Doc Brown Dec 10 '13 at 13:42
    
... and in fact, I made the experience that in big projects with many teams, enforcing the DRY principle over team boundaries can couple teams in a way together that they become totally unproductive. Sometimes its better to let teams work indepently, even for the risk of reinventing some wheels. –  Doc Brown Dec 10 '13 at 13:48
up vote 4 down vote

A lot depends on how the requirements happen to change. In a second semester programming class, we had to implement tic-tac-toe. It's a relatively small problem, which I basically brute forced with a lot of repetition.

If the requirements had changed to require the computer to win or draw 100% of the time, instead of 80%, I would have been set. Instead, the professor made it 4x4, then three dimensional. Both of those were too big to brute force manually, and I basically had to start all over each time.

Someone who had used minimax (although we hadn't learned it, so it might have been considered cheating), would only have had to change the I/O and the logic that determines a win/loss/draw.

In the real world, you typically have a very large code base, and a large team. One person is working on 4x4 tic-tac-toe while another person is simultaneously working the 3D, and you have to share as much code as possible, so you can share improvements, but also not break each other's work too much during development. That requires a highly modular, encapsulated, reusable approach.

share|improve this answer
up vote 0 down vote

Very brief answer here, Don't Repeat Yourself. If you find you doing the same lines of code over and over then that code should probably be in a function.

Why? Well imagine you find out you have to update said repeated code because its bugged, wrong or your requirements have changed, you could end up repeating you update over and over and over costing you(and therefore your company) hard cold cash.

IMHO You shouldn't feel you're doing something wrong, you've taken a specification and done exactly what was asked, if your tutor failed(or chose to omit) parts of the specification then he has his own reasons for doing so, in the real world we properly specify requirements upfront and developers who write minimal, clean code are very much valued!

share|improve this answer

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