how to program properly ?

What you are describing is the natural model of how we all write programs. Programs evolve over time - you can''t design them up front, because they are susceptible to sliding requirements and organic evolution. Instead, you should do what your intuition tells you and continue to develop how you have been so far.

However, that doesn''t mean that other techniques such as scribbling down some design ideas, or drawing a few UML diagrams cannot help you to visualise the design. Sometimes time away from the compiler helps you to think clearly. Practice and experiment, and see what works for *you*.

Also, in pursuing the intuitive techniques that you use to build programs, you need to build tools which help you to apply these techniques. If you are regularly making small changes, or "refactorings", to your program because something isn''t quite right, then you need to support yourself with tools to help you do that. Obtain and read the book "Refactoring", which describes various techniques for achieving this.

It''s usually a good idea to do as much analysis of the program before you start to hack at it. It is prudent to consider things such as future extensibility, maintainability, etc. There sre fascilities to help you, such as design patterns, templates, virtual functions, abstract classes, etc. It is also a good idea to maintain large collection of classes and functions that you can reuse in your new projects (these can be emulated in C). Given that these objects/functions are time-tested and relatively bug-free will help you out a lot when your new program starts to behave in weird manner. I find it helpful to think of a program as consisting of two orthogonal pieces; structural and functional. I leverage heavily off of design patterns to architect the structure of the program, similar to laying down foundation and plumbing. I will also consciously try to maintain independence between the structure and the functions by using abstract interfaces and virtual functions. It is not always possible to maintain the separation between the structure and functionality. But by using layer of indirections, it is possible to decouple sections of the program. In any case, if you are going to do any sizable program, it is important to think about what you are going to do before you actually start hacking. In the long run, it will save you a lotta time and reduce brain damage.

quote:

---

Original post by MetalicFog
<... stuff snipped ...>

---

I profoundly disagree with what you have written. I particularly disagree with these statements:

"It''s usually a good idea to do as much analysis of the program before you start to hack at it"

"It is prudent to consider things such as future extensibility"

You seem to be granting licence to the evils of endless procrastination and premature generalisation, and you are denying the evolutionary nature of software developments.

I have to FULLY agree with MetallicFog. Plan your software ahead with all the idea you wants. And then code.

This is obviously the theoritical way, the pratical way is to overlap them.

It doesn't make you procrastinate. It makes you think about what your are going to make. It makes you see that your code solves the problem efficiently. It makes if your code is easy to change, because you have all the modules and the interfaces properly defined.

Striving for generic code is also good, and that's because generic in programming does not means one fit-all, it means easy to fit, so reusable and extendable..

Saberman : When you say that considering future extensibility denies the evolutionnary nature of software development. I feel that it is acknowleging the evolution.

You plan your software in such a way that you know it will change and you try to ease the transformation.


But I have to say that is does not mean to write all documention and do all UML diagrams.

It simply means to think first( I don't think anybody disagree about that), because if you are writing a software that is small and consists of example > 10 classes, well you can probably do the whole process in your head.

But for a large or medium software, a good design or you will be fighting with your code at some point in time. And to have a good design, you need a good design process, which what Metallifrog wanted to say I believe.






[edited by - Gorg on April 12, 2002 3:04:14 PM]

If you got some money there is a book called Code Complete GameDev has a little bit and shows a link to Amazon.com to buy it. I own this book and I like it a lot. The url is:

http://gamedev.net/columns/books/featuredbook.asp?productid=19

Hope that helps

Jeff D

quote:

---

Original post by Gorg
I have to FULLY agree with MetallicFog.

---

Please read this paper: The Imperial Clothing Crisis. There are several areas of the s/w industry starting to wake up to the folly of traditional approaches to development. This paper is a personal favourite of mine. Also note its strong relationship with XP and refactoring. If you wish to discuss any of the ideas in the paper, please post back here and I''ll try my best.

Hi,

It sounds like you are doing alot of cutting and pasting of code. This is a good thing in some cases (You don''t have to rewrite something someone else has done), but also a bad thing if it gets out of hand. It seems as if you have cut and pasted so much code you no longer understand how it works. You have to understand how the code works before you use it.

I''m particularly anal about this because I don''t like to copy others'' code. Instead I study it and learn what they are doing, then I write my own code to mimic the behaviour of theirs. Designing your own system is much better because you know exactly what is going on. Until you become a master programmer, reinventing the wheel is precicely what you need to do in order to become better.

Need a string parser? Build one yourself.. it might be a trial by fire but it teaches you things you never consider until you try doing it yourself.

Hope that helps.

I agree with MetalicFog that planning is very important in software development. You don''t have to know every implementation detail before you start coding, but you should have a clear concept of the structure and functionality of the data your program will be using, the algorithms that will operate on the data, the user interface, and how all these pieces fit together to create a functioning computer program. Once you start coding you will make changes to the design (if you are using an evolutionary model); you should put as much work into maintaining a clean, logical design as you did into creating the design in the first place. Once the software is complete, if the final design is well done the software will be MUCH easier to maintain and add functionality to. I am a college student majoring in Computer Engineering and am taking courses in Object Oriented Programming in Java, and Software Engineering, and have begun incorporating some design into my projects (both for assignments and for fun). I have found that doing design work up front and maintaining a clean design throughout development produced the following results:

1. I was able to produce more code with more functionality in less time.
2. My code contained far fewer errors and the errors were easier to detect and correct.
3. My code is extremely easy to change later on.

In short, programming without design is just as inefficient and risky as building without a design. For small projects you may get away with it, but for moderate to large projects it is essential, and there are benefits even for small projects. The assignment I refered to in the above example was only 500 lines of code.

Okay, that''s it for now.

quote:

---

Original post by bob_the_third
I agree with MetalicFog that planning is very important in software development.

---

No, no, that''s not what he said. He used the word "analysis", which is a different thing. He also made it quite clear that you should do as much analysis as you can *before* doing *any* coding. What you said was very different, and I pretty much agree with your comments. The only thing I''d say is that you cannot make a clear distinction between design and coding. Coding, in many respects, *is* design.

quote:

---

"It is prudent to consider things such as future extensibility"

---

For the most part, it''s a waste of time, as most of the time you have very little idea what the next project will require. Instead of wasting time designing and implementing methods "just in case", design and implement what you need, and move on.

quote:

---

Original post by SabreMan

Please read this paper: The Imperial Clothing Crisis. There are several areas of the s/w industry starting to wake up to the folly of traditional approaches to development. This paper is a personal favourite of mine. Also note its strong relationship with XP and refactoring. If you wish to discuss any of the ideas in the paper, please post back here and I'll try my best.

---

Very interesting article. I bookmarked it for future reference. I agree with lots of think they say. But I don't see how this invalidates my words or MetalicFrog words. He simply pointed out tools that can help you create software.

I don't think I have ever said create your software so that it is the ultimate piece of code and can be used everywhere. I simply said solve the problem properly.

By design for changes I meant this :

Say your are developing a game engine. You have a piece of code that loads level into it. This works fine for the first version. In the next version, you want no loading screen and so you need to cache section of the worlds.

So in the first implemenation, I would have designed it so that the interface with the rest of the software does not need to be changed when moving to the other implementation has going a level loading to seemless implementation is something you would want from a video game. The rest of the implementation really has no importance for the software to be modifiable : there will always be a chunk of code to load levels!

I need to admit though that easy opportunities like that do not happen often, and I don't go hunting them, I only do the obvious one.

What I meant by "generality means easy to fit" is this : I have a piece of code that is a generic vertex array. It can holds any number of array containing any type of data.
In the application, I simply wrap this code around and simply uses the number of array I need.
With this little generic piece of code, If I want to change my vertex arrays to hold more things(tangent space, weights), then I can simply create a new wrapping class in 5 minutes. It is has been very usefull.

Easy to fit.
I have to admit there are very little generic opportunities like that in a software and I just don't go hunting for them. I just do the obvious one.

The rest of the classes pretty much only make sense in the current application(though chunk of it could be refactored for another project). I don't want to pass all my life writing the code. I need to make some money


ugh... I feel like what I said is pointless because after reading the paper and seeing your point of view in a clear way, I think we pretty much agree on the same things. Just using different wordings.






[edited by - Gorg on April 12, 2002 12:12:37 AM]

quote:

---

Original post by Anonymous Poster
Your only problem is that right now you aren''t really supposed to be reading this forum. You ought to be coding. When I have a job I''m going to buy a couple of computers. My main coding computer won''t have internet access so I''ll be able to concentrate on coding and not forums.

---

LOL, how true is that... I swear, if this computer wasn''t hooked up to the internet, I would get so much done, but with AIM and these forums available, it makes procrastination VERY common. It gets so bad where I check these forums every 30 minutes! Geez, talk about addiction... AIM, that is just as bad. Hmm, wonder what I could do to fix these addictions.. I do need an internet connection sometimes though, for reference/documentation. Back in 6th grade, when I had nothing but a 486 and a 56k connection, I got a lot done! Damn, now that I have broadband, and an Athlon 850mhz, I get nothing done. Maybe if I forced myself off broadband, it would help? I definitely wanna keep the computer an Athlon =)

quote:

---

Original post by Gorg
But I don''t see how this invalidates my words or MetalicFrog words. He simply pointed out tools that can help you create software.

---

That''s not actually what he said. He talked about doing as much analysis before beginning coding, he justified premature generalisation and he mentioned that ugly word "reuse".

quote:

---

Original post by MetalicFog
It is also a good idea to maintain large collection of classes and functions that you can reuse in your new projects (these can be emulated in C).

---

You are right Saberman. I had miss this sentence. Pretty utopic.

And what does he mean by (these can be emulated in C)??

quote:

---

Original post by Gorg
And what does he mean by (these can be emulated in C)??

---

I don''t know, but what he''s said appears to be nonsense regurgitated from so many of the OO books and papers out there, with little thought given to reality. Bear in mind that the "just do it" approach does not make for good thesis material. As soon as people stop trying to impose science and methodology onto what is basically a craft, we can all get on and actually *program*. Programming is a process requiring intelligence, intuition, experience and education. You can''t just apply a few rules and expect a correctly functioning system to drop out of the end of it.

Amen. This thread can be closed now

That''s the trouble with programming...it''s part art and part engineering. The engineering aspect deals with how you break the problem down into pieces that can be programmed efficiently and with ensuring that a design is maintained that will make the actual programming easier. The art is the actual coding itself. There are many sound design principles that can and should be used to guide the design phase of software development; however like all principles, not all of them apply to every project and those that are applied should be adapted to the project at hand. Large projects require rigorous and highly formal design methodologies some of which may include keeping a database of source and design documents for organized team reference. For smaller projects a quick diagram or two and laying out the classes required in advance may suffice. There are even times when coding CAN be part of the design, although my gut feeling is that this should be avoided (of course I still use it...). Good design is an engineering process that like all engineering processes takes an organized, rational approach to problem decomposition. There is absolutely no reason to rush into a problem (besides impatience). A little planning can save a multitude of headaches (and impossible to find bugs at 2am the night before the project due date!). Certainly you can go overboard and spend tons of time designing and never actually get around to coding, but if reason is applied a good compromise between design time and coding time can be reached.

Of course this is the way I think it OUGHT to be...I''m not in any way saying that I adhere to everything I wrote above. I''m still very much learning to incorporate the design phase into my projects (as opposed to pure coding as in the past) and with the last project I completed (for a school assignment) I incorporated some coding into the design by laying out the skeletons of my classes before actually coding the guts of my program.

quote:

---

Original post by bob_the_third
That''s the trouble with programming...it''s part art and part engineering.

---

I don''t believe it''s either of those things - it''s a craft. There''s no trouble in that as long as you can accept it as such.

I''ve been getting paid to program for last six years, and I''ve only described the procedure I use to get things done on time and with least amount of bugs. For me, reusability of code is very important. It is like an OO approach to the old cut and paste practice. Wouldn''t you agree that STL is a very useful thing? Wouldn''t you say that design patterns are useful things? Maintaining library of objects and pieces of code that I know works is a big help when you start a new project. My idea of analysis does not refer to endless head-banging considering all possibilities. It simply refers to the process of designing the software such as separating architectural and functional aspect of the program; algorithmic concerns; identifying classes; considering class interactions; etc. Writing code is a simple task if you know what you are going to type. Also the "emulate in C" was mis-placed. I was simply saying that some of the OO stuff can be done in C as well. Matter of fact, the best code I have ever seen was written C, and I learned many OO concept working on that code. Some of the worst code I ever saw was written C++ with wild abuse of OO paradigm. Without proper design, the code will evolve into spaghettie code. Of course, all my ramblings are just my opinion. Coding, I think, is a form of self expression, and different people will have different approach to it. If whatever you do works for you, then thats the way.