I prefer to put the push/pop in the class draw functions, because otherwise one class may mess up the styles or matrix settings for the others.
For example, if you translate, that is normally specific to one object or class, and you need to undo it before you go drawing other stuff elsewhere
I think it’s consistent with the principle of keeping scope as local as possible, that custom settings should also be kept as local as possible.
@RonJeffries You’re going to be a big help to the new coders. They need a lot of explaining sometimes. As for me, I never commented my code as a professional and I don’t comment my code here either. Only if someone asks for something specific. I always told my boss, the code is the comments.
Once your code gets past a page, though, comments begin to be important.
I once saw advice that said comments are not there to explain what you’re doing - clear code should make that obvious - but why you’re doing it. To me, it’s plain common sense that you comment anything that isn’t obvious and which would be confusing otherwise.
@Ignatz I always coded things as simple as I could, that helped with updates. My function names said what the function was for along with the variable names.
Yes, but that doesn’t always explain why you use the formula you did, where it came from, how a function is used elsewhere, how the code hangs together, etc
If someone else has to read a pile of code, an “executive summary/outline” is extremely useful, just as it is in a report
From my own experience, with Codea and previously, judicious comments are extremely helpful
I was taught that a comment is the code’s way of asking to be made more clear. You can do a lot with intention-revealing names and good simple code. I try never to write anything that isn’t obvious. Part of that is writing the same kind of thing the same way every time.
Except, of course, that one tries different approaches, to learn new things, to try new styles, to hone and improve one’s skills. Or just for fun. 
I agree with you, comments are helpful. They explain what you’re doing, and I think the new coders should use them. I just didn’t use them. I managed to make it to retirement without them, that’s all that matters.
Comments explaining the code are mostly evidence that the code is unclear, IMO. Explaining meta-decisions, or sources of algorithms, or the like, sure, that’s another thing.
I try to make the code tell as much of the story as it can. If it can’t , and the story needs to be told, then one tells it some other way. Your articles, Ignatz, are good examples of how to do that.
In the past, I’ve written long narratives explaining the development of a program from beginning to end. Adventures in C# is an entire book done that way. Way out of date now , sad to say. Maybe I’ll do some like that as I push forward with Codea.
You mean this.
http://xprogramming.com/acsindex/
Yes, the published book, all zillion pages… Very obsolete now, though the thought process, how I learn a new language, is probably still good. But C# is quite different now. And M$ basically never pushed any of the books in that series. Ah well. :))
And all those articles are lost somewhere in a wordpress failure now. Just as well, perhaps.
Code Complete is a pretty good resource for new programmers
Code Complete is good stuff but rather dated IMO. I’d suggest Clean Code by Bob Martin, I think.
@RonJeffries I looked up Clean Code and found a PDF version of it. I don’t think a new coder is going to read 462 pages, especially when they don’t want to read the tutorials we point out to them here. By the way, I saw the reference to you in the book.
@dave1707 — I agree, most people (such as myself) don’t like reading long books to learn something (well, most teenagers don’t).
Well, Dave, people can try to learn however they want. And if they’re here just to have fun, it surely doesn’t matter much. If they’re interested in finding positions in industry, getting paid for programming, there are still lots of ways to get there.
You and I have very different programming styles, it appears. Yet, I’ll bet that we’d find some very significant similarities if we looked. They would probably revolve around using the power of the language well, around simplicity, around avoiding duplication, and so on. The things formalists call coupling and cohesion. We might approach those things differently but would still be doing similar kinds of things in similar ways … because they work.
To get good at programming, one needs to program – a lot. Practice, practice, practice. But there’s more. We need to see different ways of doing things. We need to learn better ways – and we’ll surely learn worse ways. And we need to learn to distinguish between the better and the worse.
We learn a lot by reading code. When we read code, we can learn from the experience of the person or persons who wrote it. If we read only our own, we’re always reading the code of someone no more experienced than we are. If we read lots of people’s code, we see more options and many of them will be better than what we’ve discovered on our own, so far. (Many may not be: experienced programmers are not necessarily good ones. There’s good money to be made in cleaning up old code messes if you can stand the smell.)
We can read examples. Dave’s examples here are great and they are many. Ignatz’s as well. Probably there are others here whom I have just not found yet. Examples are nice because they can give us an isolated view of a clean solution to a single problem. That makes it much easier to learn.
And we can learn from principles. I can usually explain why I do things the way I do, because I’ve spent years trying to help people learn to be better programmers. So I had to think about what I did, why I did it, why it worked – or didn’t work.
My Adventures in C# book (not recommended here) is unique in that it is a huge book showing how I developed a large program, and it includes every single mistake I made. Try this, fail, try that. It tried to show what programming is really like, when you’re learning as you go.
To me, programming is full of lessons that come with the fun (and with the frustration). “Well, not gonna do THAT again,” is the sign of learning.
So, what’s my point? Folks can read books on programming if they want to, and they’ll learn a lot if they read good ones. Or they can find a friendly forum and separate the wheat from the chaff in the help. Or they can sit down with a pal. Or work on their own. Practice, study, pay attention.
In the end, we get better when we learn what works well, what doesn’t work so well, and why. We can get there on our own, or with help. I’m happy to have help.
And yeah, I’m in some books. Including a few I wrote. And don’t buy my new one, The Nature of Software Development expecting a programming book. It’s way more abstract than that. Some people really like it. I like it fairly well, it nearly says what I was trying to say.
Ron, I see you are expert in extreme and agile programming. I’m sure we can benefit from all that experience in this forum, especially in helping the younger users who are still at school and who haven’t had the chance of any formal training.
Well, ignatz, I’ve been around a long time and have a bit of fame in this small pond. I try to help when I can. As you’ve already seen, you and Dave, among others, know more than I do about Codea and Lua. But I will in fact try to help.
Formality … well, I don’t have none of that.
Looks like my CODEA Enlightenment project will be useful by extracting info from the code into views easy to read.
I just did this with CODEA Enlightenment :
Class Overview for Cargo-Bot
ABCMusic = class()
BaseSelect = class(Screen)
BaseStage = class(Panel)
Button = class(SpriteObj)
ChickenBox = class(Panel)
Claw = class(Panel)
Command = class(Button)
Crate = class(Panel)
CreditsScreen = class(Screen)
Events = class()
Goal = class(BaseStage)
HowScreen = class(Screen)
IO = class()
Level = class(Screen)
LevelItem = class(Panel)
LevelItemStage = class(BaseStage)
LevelSelect = class(BaseSelect)
Music = class()
PackItem = class(Panel)
PackSelect = class(BaseSelect)
Panel = class(PositionObj)
Pile = class(Panel)
Popover = class()
PositionObj = class()
Program = class(Panel)
ProgressBar = class(Panel)
RectObj = class(PositionObj)
Register = class(Panel)
Screen = class(Panel)
ScrollingTexture = class(Panel)
ShadowObj = class(SpriteObj)
ShakeDetector = class()
Smoke = class(Panel)
Sounds = class()
SplashScreen = class(Screen)
SpriteObj = class(RectObj)
Stack = class()
Stage = class(BaseStage)
StageWall = class(Panel)
StartScreen = class(Screen)
Table = class()
Toolbox = class(Panel)
TransitionScreen = class(Screen)
Tweener = class()
WinScreen = class(Screen)
@RonJeffries I agree with everything you say. When I started to learn something new, I always bought the biggest book I could find on the subject. Normally those were “the bible” type books (1000+ pages) that had everything you could ever want to know in them. They were used as a reference, because I wasn’t going to read them. Anytime I got stuck, I would look thru the book and find what I needed. I learned by trying things. I would think of different things and write code to make it happen. That’s how you learn to really program. But that’s not what’s happening now. I think a lot of the new coders want to write that app that’s going to make them rich without having to learn how to program. They’re looking for the app that will write the code for them, they just want to tell the app what they want. I’m just here to have fun and help when needed. If I want to get rich, that’s what the lottery is for. Unfortunatly that isn’t working.