@juce good advice. Actually i feel a bit squeezed inside the small ipad screen, but i never go on a pc to clean the code. A larger view might help. I wish i would have that from the ipad… Smaller font?
@luatee i am not completely sure to understand what you mean with your levelVertice. Are you talking about game levels or about class levels?
@Andrew_Stacey ok, i see. I wish i could exactly make it so that I can do so later on if I want to, i dont want to do everything first, but to be able to easily add other things later. But i am not quite there.
@Andymac3d i agree on the going as fast as possible to something that works because it helps to understande what is really needed. And my mistake might be that i am too much sticking to the available code, right. Refactoring existing code seems sometimes much more complex that starting from scratch, you are right. But when doing so, sometimes it feels as doing the same thing over and other again (because some parts wont change). But it may be a minor price to pay…
@Jmv38 - obviously, binning everything is impractical as certain granular functions and code-blocks cannot be improved on and just work fine. But certainly looking at the overall architecture and structure of the code from scratch is very useful in many circumstances once a prototype has been created.
@Jmv38, smaller font - yes, especially if you have one of those awesome retina devices! Or, AirCode - gives you more control and doesn’t steal half of your screen to render the keyboard.
@andymac3d, very good point on starting from scratch. Lately, i’ve also started to think that it might be the best way of “re-factoring”, if you can call it that :). And you’re right, it’s rather hard to do, because we get sentimentally attached to the code we’ve written, while the actual value is in the process itself, and in the errors we made, and in understanding that we acquired of how to do it better next time.
@juce - I think its more to do with ‘re-architecting’ the structure and revisiting the overall approach once a prototype has been created, rather than rewriting the existing code to be more elegant. Its like building a house… If it doesn’t have a door and windows in the first place, theres no point changing the wallpaper. 
@Jmv38, no, I haven’t tried using the documenter at all. I was just thinking it might be a part of what you are looking for.
Some good advice here and some new ideas for me to take forwards. Thanks, all.
Some general OO principles to keep in mind:
DRY - Don’t repeat yourself. If you find that you are cutting and pasting code to tweak it some minor way for each use, it’s a good candidate to put in a class or something and reuse.
KISS - Keep it simple stupid, write as little code as possible, don’t get over complicated. Class inheritence is a big OO popular technique, in Codea, I wouldn’t bother unless you have a really good reason to. Often if there’s code you need across a few classes a helper class may be better than getting deep into inheritence.
YAGNI - You ain’t gonna need it. Don’t over engineer your classes for what you may use them for in the future. Write just what you need for your program, if in the future you need a new feature, if you’ve written good code, adding that feature when you need it shouldn’t be too hard.
@jmv38 LevelVertices class contains all the games level vertices, each level is indexed by an x in the init function, if you need an example just to clear it up I can send one through pm.
thank you all for your suggestions and ideas.
Through this discussion i have come to talk about my favorite platform at work, MathCad. Why can make very complex programs easily with it? I know why, it is because i can apply a very simple but powerful set of rules: for each function:
-
specify: describe in clear text what it is supposed to do, and its inputoutput variables,
-
design: each function must fit in half the screen or less, for global view an simplicity,
-
verify: immediately after defining the function, test it. MathCad allow do this very simply with values, text, graphs or images, right in line. These test stay there and are re-run systematically once at startup, so changes in the code are tested and the result is very visual.
With these only rules i can make anything, because i build and check function from the previous valid bricks. This is 100% reliable, easy to maintain and evolve, and i get no bug.
So if i could do the same with codea i should succed. And i can see i dont follow some of these rules, for clear reasons:
-
specify: i dont always do this input/output description before each function. In the init() there are so many variables initialized, it does not make sense. In some methods, i use several self.xxx. variables and modify several self.yyy variables, it looks heavy to re-list them again at the beginning. Mathcad does not give access to such prperties, so everything comes explicitely from the function parameters call and comes out via the return parameter. Maybe i should enforce this behavior in my code?
-
design: on the ipad functions always exceed the display size, making them difficult to view in glance. Access to functions is very slow (tab browsing from extreme left to extreme right, trying to find a function, make take 15 s! And an object with many methods is a large piece of code itself, because functions interract together, they are not interacting explicitely in a small, well defined region of the code. But maybe i could emulate that, via the event model…?
-
verification: this is maybe the worst part. I do verify my code as i write it, almost line per line, but there is no easy way to place and keep the verifications right after each functions. The results appear in another panel, without the code besides, which make the reading difficult. And only text and numbers can be printed, not curves or images… And the most difficult verifications are about the GUI verification: how to code and keep that a ‘fast swipe from the left’ will do this or that? The gesture has to be hand made each time i want to re do the test, this is not practical at all… A minimalist help would be to find a wy to write the tests and results right after each function, using the capability of codea to read/write into the tabs. But that will not help for the GUI problem.
thanks to this discussion i think i have a better view of why i fail, and what would be necessary (for me) to have a reliable dev environement that helps me to build and maintain complex programs with codea. The next step would be to develop the missing tools, and see if they really make the difference… still to be proven!
Thank you all for your help.
Also: i got some hard time with classes as they are defined in codea, due to strange behavior with multilevel inheritance. I have started to drift to simply defining a table with properties and functions, and just copying them into the objects that need theses properties. This takes a little more memory, which is insignificant if i have a few objects (<1000), but avoids all the tricky problems and headaches that come with classes, and it the resulting functionnality is the same.
@Jmv38 I have never really found inheritence to be necessary, it can always be emulated some other way without the kerfuffle
maybe theguideline i was missing was the component pattern.
http://gameprogrammingpatterns.com/component.html#the-pattern
Thank you @hyrovitallyprotago
Inheritance might not be necessary, but it sure is handy. For example, Cider describes the Frame class with some simple functions related to rectangles. The Control class builds on Frame, adding some base features and properties desirable for all visible controls. The Button class builds on Control, gaining all the features of Frame and Control. However, Button overrides some features of those underlying objects, defining its own draw and touch behavior appropriate to the class. Button gets all those other functions and properties “for free” in terms of coding effort, and only has to define those points where it differs from the parent class. And because Button is a child of Control, I can often pass it to functions or classes that expect a control, even though those classes may have been designed with no knowledge of Button, and get the expected response.
Are there other approaches? Sure. But I’d argue that few of them are as ultimately easy to follow in a large project. There’s a reason why Apple (and Google, and Microsoft) build their big code this way.
I’ve written several projects (in objective-C or C++) that topped 100k lines, but good object modeling kept them under control. Design patterns can definitely be helpful, but my experience is that patterns exist as subunits of a project (factory pattern appears often for me), with the overall project rarely fitting into a neat box.
@Marl thanks for the remark.
I was not clear about inheritance: i love it and it makes great sense. It is just that, sevral times when working on big projects on codea, using 6-7 levels of class inheritance, i couldnt do what i needed due to a strange bug at compilation (i made a thread on that once, but i dont remember the details), and i didnt find a nice way around the init() being overwritten by the child class. In my code i just need a clear, simple inheritance process to agregate decoupled functionnalities, and some garantee i am following the right path, not to fail in the end. The component pattern seems to be made just for this, so it makes me pretty much excited and hopeful!
My problem is merely about:
minimizing the amount of knowledge you need to have in-cranium before you can make progress.
and i know i am unskilled newbee in OOP and i dont mean to give advices to anyone here concerning class(), i am just trying to find my route to making big evolutive programs with codea, after having consistently failed at this for 2-3 years now, which is frustrating. After all this time and effort, i have noticed i cannot really re-use my old code parts, and this is not good, i’ll go nowhere if i cannot re-use simply and reliably. I hope some good methodology will help me achieve this.
@Mark I didn’t mean to say don’t use inheritence, but just use it judiciously. I’ve been involved in a number of projects where inheritence was used heavily to many levels deep, and with a good desktop IDE (eg visual studio) it’s quite easy to browse, but even then you can get lost quite easily if certain behaviours are overridden at some point in the inheritence chain. On the iPad it’s even easier to get lost.
So like any technical approach, it’s incredibly useful, but shouldn’t be a default arbitrary behaviour, use it where it adds value and try and avoid the complexity where it doesn’t add value.