Quote: Original post by llvllatrix
How does code grow? As far as I can tell there are two main ways code can grow. It grows on a macro scale and a micro scale. Your design should consider the macro scale of code before you begin implementing, but it’s not unusual for your initial considerations to change throughout the development. Here is a list of different macro scales for different complexities of solutions:

1. single function program (hello world)
2. multi function/class program (school projects)
3. multi subsystem program compiled into a single app (this project)
4. single app that uses dlls or plugins
5. user/client apps (usually networked games)
6. multi apps on one cpu (Microsoft Office/Windows)
7. multi apps on multi cpus (think mmorpg servers)
8. Protocols (the internet)

The scale you select depends on the solution you are targeting, so you usually have an idea of what you will need before you start the project. You divide your project into more and more pieces to make it maintainable, and as a result feasible. At each division you can test and grow your code independent of the other levels.

Quote: Programmer growth:

A bit of a side track: It seems as though a few of my friends have had similar experiences when it comes to our growth as programmers. In general, we all seem to be developing an instinct for what I think is good design. This instinct tends to be directly related to the level you can program/engineer. I encourage you to share your experiences on this thread as it seems the development of this instinct is different from programmer to programmer.

Quote: Naming:

Why is naming important and what is it used for? From my experience naming can be used for a variety of things. It's simply another programming tool and its importance depends on what you are using it for. In this section I'll discuss two naming conventions I've run into.

Quote: When designing a naming convention the most important element is consistency.

Quote: Naming conventions tend to be affected by the size of the team working on the project. The size of the team is important because as the team grows larger it becomes harder to enforce the convention. Successful conventions make it easy to be consistent because there are fewer special cases.

Quote: Large team:

Naming conventions have to be more flexible as the size of the team grows. Here are the rules of a large scale convention I've used:

- All names must begin with a lower case.
- Any successive words in the name must start with upper case. For example the name "Chess Programming Tutorial" would look like "chessProgrammingTutorial".

You can determine easily where a name starts. You can also easily read the name since the beginning of each successive word is obvious. The following rules are optional:

- All function names should begin with a verb
- All class names should begin with a noun

You'll notice that there is nothing that specifies which subsystem a function or class belongs to. This is because large companies usually invest a lot of time developing coding tools. A tool to help a programmer parse code would make subsystem naming obsolete.

Quote: Small team:

When the team size is relatively small (1-10 programmers) then maintaining a strict naming convention is easier. Moreover, since we don’t have time to develop coding tools we can use the naming convention to solve some of our problems. Here are the rules of my personal naming/formatting system:

- All files need to be preformatted using a macro (will provide mine in the tools section of this post).
- Names for functions/classes are all lower case.
- Successive words in the name are separated by underscores. For example the name "Chess Programming Tutorial" would look like "chess_programming_tutorial".
- Your code needs to be organized into subsystems (also called slices or units).
- Each subsystem is assigned a three to four letter acronym that precedes any global names used in that subsystem. For example a window creation function might look like "wnd_create_window();".
- If there are further divisions in your subsystem repeat the same pattern of assigning an acronym. For example a gl creation function might look like "wnd_gl_create_gl_window()".

There are two reasons for the acronyms. The first is visual sorting; you can easily tell which area of the code the function/class came from. You also know where to look to find similar members of the same subsystem as well as documentation on how to use them (via comments). The second reason is that it lets you determine the scope of a function/class. You can easily tell which parts of your code are local (i.e. declared right then and there) or global because local names don’t have a prefix and tend to be shorter. Just remember that the programmer you are trying to stop from wrecking your code is yourself :)

Quote: The second and third tools I mentioned earlier are essentially the same type of thing. The dos prompt basecode is essentially a console app with the following code:

#include <iostream>using namespace std;void main(void){    //test code here}

Quote: Now that all of the preamble stuff is out of the way we can finally move on to the game...Here’s a pictorial representation of our project so far...at least my interpretation :) :

                 Chess                   | 1                   |                   | 1..n                 Scene                   ^                   | derives                   |                 Game                   | 1   +---------------+------------+   | 0..2          | 0..2       | 1 Human        Artificial      BoardOpponent     Intelligence       | 1                           +----+----+                           | 0..32   | 1                         Piece     Model                           | 1       | 1                           +---------+

Quote: You'll notice that there is a big node called "The Great Unknown". The nice thing about design is that you don’t necessarily have to plan the entire project beforehand. We can design, implement, and test in small units.

Quote: The context management subsystem:

Quote:

bool game_is_game_in_focus(void){    return con_man_is_con_in_focus(con_index);}

Quote:
Has anyone written any code yet????

Quote:
but how to link the coding with the picture....

Quote:
You could just write the entire design in a design document then post it for download in one post, instead of writing a whole bunch of posts.

while(con_man_game_in_progress()){    // Update our utility subsystems    util_update();    // Update our Main screen context    main_con_update();    // Update our Game screen context    game_con_update();    // Update our Menu screen context    menu_con_update();    // Update our Console screen context    cnsl_con_update();}

Quote:
Do we need to add the above design...