Difference between revisions of "Talk:C plus plus version"

Revision as of 13:04, 11 May 2006

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)