I am putting this here both to help future users and because I need help myself.

(Most of these stem from me being just flat out lazy)

1) Messy code.

I'll keep old crap that doesn't work, just maybe with a new conditional statement, and it will just keep getting bigger and bigger, messier and messier. I've had some (supposedly) easy and quick things rapidly spiral into 250-line monoliths, costing me hours and probably some eye/brain/finger/face damage, too.

I can fix this by choosing to select and delete dysfunctional code, instead of literally dumping more onto the problem. ("Hey, there's a fire. Let's go put it out with gasoline/petrol")

2) I want to know what your opinion on this one is.

I tend to lean towards getting a working model done, then adding shiny bells and whistles (like features, decoration, textures, music, optimization, etc) later, but I also tend to create demonstrations (I.E. Linevolution and Expression Evolution, and... uhhh... I can't tell you ), where it's more focused on showing off a cool concept vs presenting a full project.

Which do you think is better (for small programs):

Get the idea working, then optimize.
Plan everything and optimize while planning.

I definitely think that planning is needed for any real project (any project that isn't sketching your thoughts out), and I learned it the hard way during CC20, where I spent nearly 100 hours doing things that could have been prevented (yes, I counted up my time)

3) Comments.

I rarely comment my code because:
a) not commenting forces me to look back through the program occasionally, and I'll potentially find a bug.
b) it wastes my time. I could have written an entire game in the time it is taking me to write this post in "English"
c) Most of the time, I don't need it. I can probably tell what draw() does. With concise enough variable/struct/class/program/executable names, I find them more of a hassle than not.
d) In Java, <oversimplification, I'll be showing this post to some non-programmers at my school> there are special types of comments that you can attach to variables and functions. They can hold data about that function. I use them very frequently, as my IDE (Eclipse Luna. I really need to update, but I love it so much) generates it for me. (Because settings and addons and fun stuff)

4) I'm very picky with my programming language. 'nuff said.

5) There's probably a lot more, so if you see any glaring flaws in my programming, please tell me.

(I'll edit this post; I have more, but not enough time.)

1) I have a similar problem with keeping stuff that doesn't work although I don't keep it for long.

2) Get the idea working, then optimize. it's hard to optimize when nothing works

3) Commenting isn't for describing every single line I use it more with describing what a cietain chunk of code does. (i.e. //This is where the build process is, //This converts the list into a string, //This displays all the sprites, etc. ) I also comment what every slot of a list does since I know several days from now I'm not going to remember what ʟTEST(4) is.

4) it's hard to be picky when you only know 2 languages. I'm talking to myself on this one

I haven't done any serious coding in a decade, but, a few comments.

"1) Messy code."

You can get into the habit of writing neat code fairly easily proper indentation and proper spacing. It helps when you get into objects, etc.

Get rid of old code that doesn't work... it just clutters things up and makes the 'real' code more legible... and, less likely to make a coding error.

"2) I want to know what your opinion on this one is."

I generally used to prototype a part of code and then 'fill in the blanks'. It makes writing large programs a lot easier... some of my coding had over a meg in source code.

"Get the idea working, then optimize."

Optimising is far less critical when you are running with current computer systems... with the old 8088 and that ilk, I often used to insert parts of Assembly Language just to speed things up.

I'm not up to speed with the TI NspireCX CAS, but, because it's interpreted, there may be optomisations that will speed things up.

Current CPU's default to something better than double precision and by compiling on single precision as a new default, your program may actually run slower.

"Plan everything and optimize while planning."

Optimise after coding with a little pre-planning... find out where your code runs 'slow' and then put the efforts to fixing it.

"I learned it the hard way during CC20, where I spent nearly 100 hours doing things that could have been prevented (yes, I counted up my time)"

Enlightening, isn't it... now, why didn't I think of that before... have often scrapped large blocks of code just simply because I started it wrong.

"3) Comments.
I rarely comment my code because:"

It interferes with the 'flow of coding'.

It's a good idea to go back and add a few comments... also with programs and functions I have a standard 'header' where I list variables, etc. or a brief clear description of what the code does. It's easier to read a few months down the road. Also try to get into preparing 'black boxes' that are functions that do a specific task, and use them often.

"4) I'm very picky with my programming language. 'nuff said."

Almost any high level language has a robust set of tools and by choosing the correct one, you get used to the constructs. I don't do web or cloud programming... most of my later stuff was done in Delphi which is a Pascal type of language... it has the ease of Visual Basic and the power of C++. I used to do a lot of coding in Basic because the math library was a lot faster than the C and C++. Most of my coding was mathematical. C is nice for its simplicity and C++ for objects and commenting... I used to use C++ because commenting was easy and it was easy to comment out a 'block of code'.

a few ramblings...

Should have added... you have to know your compiler... and with critical code actually run some 'timing loops' just to see what works faster.

Dik

To me, I'm used to messy code. You get used to no indents when all you used to do is program on-calc. Of course, properly indented code is much better on the eyes, but in my opinion, not one of the really important things.


I do a mix of both. If I see something that can be readily optimized while I'm programming, then I do it. But if it's a problem, I usually do one of two things:
I either write it down, and keep going, or fix it right then and there. Usually, I pick the second option.


While I understand why you don't want to, it is very helpful to those of us who read your code, and it can be the difference between a 5-seconond understanding of the code, or a half-hour long session full of "What's this?" and "What does this block do?". As I said above, not important, but very helpful.

Same here.


Try to learn psuedocode. It's where you look at the flow of your code, and line-by-line, "run" your program. It worked for me when I was programming my first C program, and it made a few not-so-obvious errors came out. Try it.

I personally don't use pseudocode too much in my TI-BASIC programming, as I'm accustomed to the language enough to be able to run those programs in my head with a sheet of paper to store variables, if needed.

If I'm doing programming in, say, c, I'll use excessive amounts of pseudocode, unless it's for CC20.

Yeah, everyone does this from time to time. Out of everything in your list, this is the big one. More experience will give you the confidence to just delete bad code and rewrite it.



Always this. Literally always.



Comment things that look complicated.

When you have something like...

Code:

...you're going to want an english explanation when you have to go back over it.



Not really sure what you mean, but I'm a mobile dev so my options are... limited.

Comments are my savior. I comment everything. It helps with debugging and with understanding what the code does. It makes my code more readable and allows me to follow the comments rather than decipher the code. It also makes it easier if someone were to come and take over my projects.

I may not document what draw() does but I will document what it draws. Such as
// Now that we've got the elements, let's draw the enemy ship.

Messy code

I think it just sort of happens. Like your house, messy code sometimes seems to be an inevitability no matter what you do. But that's when it's time to stop and clean things up before it gets too out of hand (or especially if it already has!). That can take some discipline since it's not as fun as continuing to write new, exciting code. But the same thing goes for housework.…

My favorite way to “fix” accumulation of junk code is using revision control systems (like Git, etc.). They're nice because you can hang onto as much broken, junky code or failed ideas as you want without actually cluttering up your working version. Sometimes you might think an approach isn't going well and try another one, only to decide that maybe your original “failed” attempt wasn't so bad after all or that it can be adapted into yet another possible working approach. Then, being able to dig into that archive of “bad” code can come in handy. The fact that you always have a revision history of all your work also makes it possible to confidently and unhesitatingly rip out whole sections of code that you think aren't helping. You can always get them back from a previous commit if needed. No need to leave huge, commented-out hunks of code lying around in the working revision for eternity.

Unfortunately, this isn't an option when one is writing code directly on the calculator, as far as I know (hmm, possible project idea for any ambitious coders out there? ).


Working code

Preliminary planning isn't a bad idea, but when it comes to the actual coding stage, I lean toward the opinion of getting it working first. Working code that's slow is better than code that runs really fast but blows up the city just before it crashes. If the code is at least working, then it's easy to try some optimizations (one at a time) and see if it works, or roll back and try something else if it doesn't. If the code works but is messy or has bad architecture, it can always be cleaned up or refactored later, preferably one step at a time with a testing and “un-borkification” phase after each. (Again, RCSs come in handy here since it's trivial to rewind a few revisions if things happen to go really sour.)

Also, not all needed optimizations may be clear during the planning stage. No matter how much planning you do, you'll probably run into something you didn't anticipate when trying to get the code working.


Comments

I try to write my code to be as clear and readable as possible without comments, but if I think there's something I might be confused about in the future when I look back at the code (or once I figure it out, when this actually happens), I try to remember to add them. They're also good for documenting logic that at first glance might look wrong or pointless but was actually put there for a good reason.

One rule of thumb I've heard is that comments shouldn't be used to explain what your code does, as the code itself already says that, but rather why it's being done that way. Or at least, they should explain something that isn't obvious from looking at the code itself.

On the other hand, if you find yourself using comments to explain things like what some weird variable name is, or what some really, really weird-looking complicated expression or regex is and how it works, maybe it would be a better idea to rewrite the code to be more legible in the first place.



I know what you mean. I'm refactoring some smart light scripts I wrote. I bought some Philips Hue color LED bulbs around the beginning of the month and had a lot of fun making the lights do all sorts of cool color shows and stuff. In the excitement I rushed through coding the scripts and was left with a bunch of different programs that did cool things but had redundant routines and boilerplate copy-pasted into every script. So I wanted to fix that up into proper modules and classes before it became unmanageable. In the middle of that, I discovered Pylint, and then got obsessed with fixing all the picky things it complained about, and suddenly the refactoring job became even more drawn out and complicated.

Maybe I'm getting a little carried away. But it's also a good chance for me to learn some new coding practices and learn what code organization approaches work best. While this refactoring work is a really tedious and not-terribly-thrilling job, once I finish it will be a lot quicker and more pleasant to continue enhancing / bug-fixing / adding to the code, and I'll be able to have fun again.

(1+2) SDLC (software development lifecycle) which means the dev process is in a constant loop of evolution which goes something like -->> Analysis -> Design -> Coding -> Testing -> etc

in particular your comment 'Plan everything and optimize while planning.' is normally impossible, even for small programs.

(3) You will learn to comment properly and effectively with time, but basically your code SHOULD be self-documenting. Comments are A very good thing.

(4) Good.

(5) I haven't seen any! Lol