Talk:C plus plus version

That should mean as well avoiding macros, avoiding globals, avoiding to split classes over many files and using a consistent naming scheme, but judging by the current state of the code, it doesn't. -Sprotiel

First of all, I find it incredibly irratating that you don't bring gripes about my style (which is inevitable because everyone's style is different. I don't think I've ever found a coder call someone else's code pretty) to me face to face, and instead post passive aggressive comments in various places. If you don't like something I do talk to me about it. Please cite and show me areas you find to be obtuse and suggest an alternate way that I should have done it. I'm an expert in C++, expert enough to know there are still things I can learn.

That said: My beginning use of macros is still somewhat experimental. They are primarily used in areas where they help increase maintainability (if not readability), especially in the GUI code (a million function calls all but identical). They are also used in areas (such as the new Vector setup) where templates are just going to make things messy (MSVC doesn't handle advanced templating very well, especially in the form of inlining classes. MSVC came out before they ANSIed the language.)

As to naming scheme, I think it's quite consistant except in areas that are what I would call "grandfather" code. IE: that's how the code was set up in the VB system, so that's how all the coders are familiar with it. In general ThisIsMyNamingSchemeAndIThinkItWorksQuiteWell. I have seen worse.

I have recently begun moving some various class functions away from being grouped in the same file and instead group them on common purpose. IE: Robot functions dealing with ties in ties.cpp. This was after months of flipping between two different .cpp files while I was working on a certain system. They make it easier on me, the principal coder. Or maybe you mean splitting the robots class across different .cpps. Have you seen the size of the Robot class? Robots.cpp is already the longest file in the whole project!

Globals are not bad. They are only bad if you're after an object oriented design. It should be pretty obvious I'm not. I have no idea what my programming style is called, but it's the style I've found myself to be the most productive in. I find it also to be the style that makes the most sense to me years later when I go back and look at my code. Having worked on the C++ version since October, I still feel that the code is reasonably well organized and maintainable. The globals in the code are only those objects which are indeed global in nature. Or that's the idea.

It's 12000 lines of code, there might very well be some areas that aren't pretty. I admit it. But I know what all those 12000 lines of code do. It's written in the way my mind thinks. I could come back to it in 10 years and still probably figure out what's going on in most of the code. I can't say the same for the vast majority of code I've seen others write.

Perhaps if you wrote some of the code it would reflect the way your mind works.

--Numsgil 18:09, 8 May 2006 (MST)

Aggressive ? I guess I was, because I was frustrated at the amount of time I had to spend to understand some small part of the code. Anyway, the core issue is that the code you write isn't C++, but an idiosyncratic mix of C logic and C++ syntax, for which there exists no guidelines and no documentation. It may be readable for you, but it has little chance of being readable for anyone else. As it happens, I spend more time trying to understand your code and to figure out how to make the implementation I imagined palatable to you with than really thinking about implementation and coding. Actually, I'm quite tempted to fork the code and switch to OO-programming, except that I doubt I have the patience needed to achieve anything worth it. Sprotiel 09:57, 9 May 2006 (MST)

The code isn't as well documented as it could be. It's still better than most other hobby source I've looked at recently. If there's a part that you find obtuse, feel free to add comments to it to help clarify. I think you'll be spending a great deal of time deciphering new source code, that's universal for every project, especially one with thousands of lines of interdependant code. --Numsgil 11:49, 9 May 2006 (MST)

Comments (or the possible lack of them) aren't really a problem. My problem is that it's unreasonably hard to understand what a class or a function does, and where it's located. Sprotiel 11:04, 11 May 2006 (MST)

If you're running MSVC, you can right click on a function call, select "go to definition" or "go to reference", and it'll show you what the function does or where it's called. The class list also is useful for this. Likewise "find in files" is useful for finding things. Function names should also (especially for non GUI things, such as the core engine) be fairly self explanatory. If they're not, then they probably could use some more thought as to their nomenclature.

If that doesn't help you understand what a function does, then probably it is an issue with comments. They're unfortunately spartan at the moment. I haven't had to explain any of the code to anyone else, so I don't always see what is unclear to others (since it's all clear to me).

The code is organized into files in a procedural programming methodology. That is, instead of being divided into files based on class, functions are divided into files based on common function (which is closely analogous, but not perfectly so, the class the functions belong to). Inside each file there are local globals for things that are generally universal to that common functionality and doesn't need to be seen outside the module. Ties.cpp, for instance, has many Robot class functions in it that deal with firing ties, etc. Shots.cpp likewise. The GUI is somewhat of a mess, but I'm still playing around with various styles to handle it, making it cleaner. Probably implement a more OO style in the GUI since that seems to be what the GUI library was designed for ;) --Numsgil 12:35, 11 May 2006 (MST)