Trade: Mistakes for Knowledge

[montrom]

Very nice addition. Thanks Solar.

Does anyone think we should start trying to organize this stuff while its still small? Maybe start tossing these things on a wiki page, maybe for the Getting Started area or something. What do you guys think? Anyone against doing so? I figured that if we all agree to do that, that we would just start adding things directly there instead of here and we could place a link to this thread at the bottom. Just an idea.

[Solar]

Honestly, I think everything said in this thread is "Good Programming 101". This should be on any general programming Wiki, but I don't think it mixes too well with OS development...

[montrom]

How much of what was posted would you say is related to OS Development, if any?

[Combuster]

Apart from having multiple test environments, nothing is really OS-development specific.

Cornercase design: Do not work from the average case when building a design, but instead work from all the possible extremities. This yields a design which covers everything cleanly, instead of one that uses a bunch hacks to support non-standard cases. Use refactor-first approaches when you find new cornercases for the same reason.

[Solar]

How much of what was posted would you say is related to OS Development, if any?

Nothing. Even the multiple test environment case holds true for application software just as well.

[montrom]

And, how much of what was posted would you say is related to the OS Developer, if any?

[Combuster]

Everything said applies to any big project.

[qw]

Including OS Development.

[Solar]

Seconded.

I expessed myself wrongly, sorry.

What I wanted to say is that the things said in this thread are generic programming lore, in no way specific to OS development. And that, as such, I don't see the necessity of archiving this common knowledge in the OS Dev wiki.

[~]

Apart from having multiple test environments, nothing is really OS-development specific.

Cornercase design: Do not work from the average case when building a design, but instead work from all the possible extremities. This yields a design which covers everything cleanly, instead of one that uses a bunch hacks to support non-standard cases. Use refactor-first approaches when you find new cornercases for the same reason.

Also it is convenient to know the different ways of doing a same task before deciding on integrating the most adequate way for a project, which might not be obvious otherwise. For eaxample, having available samples of all the different memory management algorithms along clearly stated theory and a glossary is a good way to see how they work and see which one is better suited to a specific need.

By the way, a glossary seems very irrelevant but it is vital to understand what is being told in any engineering or scientific field.

What would be very useful is pointing out what things are specific to OS development, and accumulate/document this knowledge. However, it might be hard to say because what was originally intended to support OS infrastructure could be used totally or in part as ideas for any other purpose, and vice-versa.

So it seems it's not about telling what's specific to OS development or not, but more exactly the things that go beyond the basic programming skills, like specific ways of doing something (like the very specific requirements AND actual methods to parse HTML over other data and why or why not to do things a certain way, or how to actually handle different kinds of peripherals that make access different from others). It is really not enough to have the full source code abundantly commented if you aren't given the theory and as much background as possible.

The next best thing is constantly reading the technical documentation, books and other tutorials nonstop but at a logical and patient pace, but without the guidance of the people who have the actual knowledge it's harder to do, yet not impossible.

Take into account as well that most people looking for information here or anywhere else in the Internet in this way lack even good basic programming skills and/or actual knowledge, but that's the very best they got, either studying in a (flawed) institution or by themselves.

------------------------------------------
So, it looks like what those generic practices have to do with OS development is the fact that somebody discovers them while working in OS development, thus directly linking those practices with it. Another person might "discover" those practices while developing a web portal, or maybe learning to program professional Windows or Linux user applications, and they will link those programming methodologies with those tasks, but they would find them to have a broader reach when working in different categorized programming levels.

[Neolander]

Yet another one :
Keep functions small and test early : So you just completed you 2K-LOC function. Great. Now, how are you going to find which parts need testing in it ? It's better to make small functions, and to test those as soon as they are completed in a multitude of way. Just another good general-purpose programming practice, that becomes especially important when you get into OSdeving

[fronty]

Write good test suites. If possible, write a test case for every feature you add. When you discover a bug, fix it and add a test case for it to your test suite. Don't forget test cases which should fail.

Though not very applicable to kernel development, but very useful for many types of software. When I started writing broad test suites for compilers, I realised how nice them can be.

[montrom]

Hi, I went ahead a created a page in my talk area for this thread. Please take a look at it and feel free to edit it in a constructive manner if you find it necessary to do so in anyway. Also, if anyone would like to contribute further to this thread, then please I urge you to instead update the wiki page I have created, but if you choose not to, then I will go ahead and add it for you. Not all things were included on the page, I'm sorry to anyone who contributed but did not make it to the wiki page. And, finally, if anyone would like to make any drastic changes, please begin a discussion first before making any really drastic edits or reverts. And, try to stick with the format/subject of the page. Also, if you decide to add information that could use its own sub section, then please create one for it. Thanks in advance.

Link: http://wiki.osdev.org/User_talk:Montrom

[sprints]

.gitignore tip
Every line that you put is a valid pattern so use # (the comment indicator) if you want white space

'' and "" difference in C
'a' is typecast as (char)
whereas "a" is typecast as (char *)

Colors in bash
Its worth writing them into your buildscripts if you have trouble keeping track of different code compiles

Types
Its always worth to take the extra time to write out the entire type declaration and to name your custom typedefs as something understandable

Scroll click in gedit
Seems to work as a paste shortcut

[qw]

'a' is typecast as (char)

AFAIK, in C++ character constants ar of type char, in C they are of type int.