How to manage large amount of code ?When i start creating something with over 400 lines of got it becomes like a http://en.wikipedia.org/wiki/Big_ball_of_mud
How do I create the DX Device (in a class,struct etc) how to reuse it,how to add modules without editing 300 out of 400 lines etc .
Is there an article written with good coding practicies,because the more code I have the worse it becomes.
How to manage code ?
A famous C++ guy once said, "Lot's of PERL usually equals unmaintainable." I find there's some truth to that. With C++ things can go wrong also if you don't work on refactoring and cleaning stuff up. I have over 5,000 lines of open source code and it hasn't turned into mud, but is fairly well-structured. That is partly because of advice from people here and on other forums. Over the years I've asked questions on a lot of forums and have taken the time to work a lot of the advice into what I was working on.
Well managed code is a skill of its own and developes with practice. In general, I'd say that once you are comfortable with identifying reusable code, start with basic object-oriented concepts and then move code into separate source files to emphasize the point.
If you are already comfortable with employing classes, I'd suggest reading up on http://en.wikipedia.org/wiki/Design_Patterns.
If you are already comfortable with employing classes, I'd suggest reading up on http://en.wikipedia.org/wiki/Design_Patterns.
How to manage large amount of code ?When i start creating something with over 400 lines of got it becomes like a http://en.wikipedia....Big_ball_of_mud
How do I create the DX Device (in a class,struct etc) how to reuse it,how to add modules without editing 300 out of 400 lines etc .
Can you learn to play an instrument by reading a book ? Well, practise is the key, coding is nothing else. Read about the basic concepts like OOP, then start coding and make misstakes, because we learn by failure.
In my youth I coded a RPG for the amiga in assembler: 50000 lines of code (in asm not that hard) in one single file and using at most 4 letter labels... the game was ok, but it was unmaintainable ... I will never again make this misstake
Maybe I missed it, but the most obvious and simplest method is not mentioned:
Use multiple files. That's what "#include" is for (um.. this is not a very precise statement but you get the idea).
Closely related stuff should go into one file. Like mouse handling, window and graphics setup, rendering, whatever.
That way, as you make more programs, it will be pretty easy to discover what you can reuse from older projects, and you will soon have a reusable little "libraries" of your own (these include files) that you can share without editing between your newer projects.
Maybe I misunderstood, and my post is too obvious.
Use multiple files. That's what "#include" is for (um.. this is not a very precise statement but you get the idea).
Closely related stuff should go into one file. Like mouse handling, window and graphics setup, rendering, whatever.
That way, as you make more programs, it will be pretty easy to discover what you can reuse from older projects, and you will soon have a reusable little "libraries" of your own (these include files) that you can share without editing between your newer projects.
Maybe I misunderstood, and my post is too obvious.
I highly recommend the book "Clean Code" (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). It has a lot of good advice on the matter.
My largest project is 170k lines of code. It's surprisingly manageable because everything is separated into well-defined classes and objects with one file per class, in turn organized in categorical folders. When I need to make a change I typically only have to edit a single file thanks to relatively strict OOP. Adding code is easy thanks to the existing architecture. Everything has a logical place.
That said, eventually you will get to that point where code management and architecture becomes just as important as the code itself. You really have to consider the user of your code, even if the user is your future self.
That said, eventually you will get to that point where code management and architecture becomes just as important as the code itself. You really have to consider the user of your code, even if the user is your future self.
I like to define and use interfaces so that I can use different implementations. You might want to look into IOC (inversion of control) options for your language of choice.
Another thing you might want to try ... to see if it works for you is test driven development.
Fans say that it forces you to think about the structure of what you need when you usually fall into the trap of writing code that is not general enough.
There are great general articles at http://www.javacodegeeks.com ... general as in programming language independent. Some I have read:
http://www.javacodeg...ve-written.html
http://www.javacodeg...hould-know.html
http://www.javacodeg...whats-your.html
The most important principle IMO is red, green, refactor (probably based on test driven development). Don't skip the refactoring part.
Another thing you might want to try ... to see if it works for you is test driven development.
Fans say that it forces you to think about the structure of what you need when you usually fall into the trap of writing code that is not general enough.
There are great general articles at http://www.javacodegeeks.com ... general as in programming language independent. Some I have read:
http://www.javacodeg...ve-written.html
http://www.javacodeg...hould-know.html
http://www.javacodeg...whats-your.html
The most important principle IMO is red, green, refactor (probably based on test driven development). Don't skip the refactoring part.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
