Thread: My new project

Hi, my new project is called SPM, which stands for "Science Projects Manager/Maker".
It will be a program which allows you to create a science projects, it will first ask what to listen to, ie. electrical impulses, and then what to search for in collected data, ie. number sequences, and then it creates a c program that has functions that you entered...What do you think? Have you got any advices on listening to and searching part...I have only el impulses thing for now...

I think this must be the third or fourth time you've used this title yann . This one may take the cake for complexity tho...

Some things to keep in mind about software design:
1) do not come up with a design where it will be impossible to test anything until you have written 500 lines. You should be able to compile and test your code every ten minutes/less than 20 lines. By "test" I mean you should be able to throw some printf() statements in to verify that your variables have the values you think they should. Or something similar to that.
2) decide what the ABSOLUTE simplest set of features would be, and focus on those initially.
3) whenever possible, use loops & variables to implement repetition (with variation) instead of cutting and pasting lines and changing one or two details -- which you, yann, seem to have been very guilty of this in the past.
4) when you write a function, try to think of giving it as many parameters as you can. This may sound silly, but the idea is like this: say you want to get some data out of a file. Rather than write a function to get that particular data out of that particular file, try and make the function as generic as possible, in other words, so that it could get a variety of data out of any file. If, when you are finally finished, you realize some of your functions have parameters that are not used, etc, you can go back and optimize those out.

These last two are really crucial IMO. It helps prevent you from repeating yourself unnecessarily, which means all the code that does a particular task is as centralized and condensed as possible. When you are unsure about something, this can make a HUGE difference. It makes it very easy to test a hunch, because there is not much to change. Otherwise, you may dismiss your hunch because it would require too much reworking of code, and often hunches do not pay off. But often they do! To top that off, it becomes much easier to conceive of what CAN be done with the code you have as is.

Originally Posted by yann

I have only el impulses thing for now...

So, stick to that for now and don't even think about anything else, coding wise. Start small, and expand. It's better to do one thing well and thoroughly than 10 things poorly.

ps. "ie" means "in other words". "eg" means "for example". A lot of adult, native English speakers mix these up as you do in the OP. I just mention this since when you are reading documentation, this is an important distinction -- when I say "in other words" I certainly DON'T mean "for example".

OK, idea is very very simple, this is the second time i use this title :P.

I know that eg. means for example, but my whole life I was thinking that ie. means "in example" o.0