I found it helpful to have small self-contained fragments of code to maintain ( if this is English ).
It does not help against ill-named variables, but it reduces their effect significantly. I am writing this because less strictly typed languages downright invite you to write comfortable code instead of watching efficiency. Especially when you confound data types in mixed structures, it can be *helpful* to re-use variable-names.

Scope is extremely important then.

Having given up all programming languages other than Ruby, I cannot but praise the object oriented way of thinking and coding with this language (and similar that I do not even know). In a procedural code, much of the charms of such a language become a curse and have to be avoided or watched very closely, which is *not* comfortable and bears other risks.

I read somewhere that the near disaster on Apollo 13 was caused by a Fortran program in which a comma in the header of a loop was accidentally replaced by a stop (an easy mistake to make while typing). As a result, part of what should have been the loop control string became a decimal value and the initial do command merged with an earlier part of the control string to create a new variable to be set equal to that value. And of course the actual loop did not run.

But if that is true, then the real cause of the disaster was the Fortran compiler's readiness to accept an undeclared variable. If that had happened in a C program, the compiler would have flagged the error at once because decent programming languages don't allow undeclared variables.

2 members found this post helpful.

Two more things that I learned about programming in C:

1) The first time you compile a program, there are usually dozens of error messages and most of them roll off the top of the terminal. Do not be tempted to try to deal with the ones that still show. You will probably find nothing wrong with that code. Scroll back to the beginning and note the first error reported. If it is a true error and not just a warning, it will have prevented that line from being compiled, causing a cascade of derivative errors further down. Fix it (and any other obvious errors that you can see in that first few lines of output). Then run make again. There will be far fewer errors this time.

2) Never ignore the warning "Assignment makes x out of y without a cast", where x and y are variable types. Mostly warnings can be ignored but not that one. Because if you have really assigned an expression of type y to a variable of type x, it is far more likely that you have used the wrong variable name than that you forgot to do a formal type cast.

I've lately been playing with C++ for the Arduino (a package very-strangely named "Sloeber"), while creating a new and evil "gadget Geocache." I have definitely experienced the "error-message hemorrhage."

It can be the very slightest thing – and the "profusion of messages" might not point it out or even be relevant to the true problem. "It could be a comma ..." The error-messages are frankly "not very good at all." And, you see this a lot sometimes: it kinda feels like watching a car crash in slow motion . . .

I like to adopt the strategy of "compile often." Make a few changes, and hit compile. "The code isn't complete yet, but make sure it still compiles." If something goes bonkers, it's got to be related to what you just did, and it's best to catch that tpyo right away. (Read it again. Did you see the typo?)

I also use the git version-control system ... constantly. (This system is entirely file-based and does not require a "server." Thanks, Linus ...)

Make a little incremental change, get it to compile, and "commit." This now becomes a "very recent" point, at which you knew "everything compiled," that you can if necessary revert to. "Little baby steps." I also give each commit a meaningful one-liner description. If I'm exploring an idea that I might not want to keep, I "branch," and if I decide to keep it I "merge." git is faithfully tracking my every change, and giving me a reliable "way out."

(If the final code is going to be published to some repository somewhere, I use the rebase feature to "coalesce" my "many in-progress commits" to a single one that is more reasonable before pushing it. No one cares or wants to see how I "crawled" to get to the finish line.)

- - -

The first thing that I'd say to anyone who is "just getting into programming" is: "just persevere." Because, once you get the hang of it (and, you will ...), it's positively addictive. You are actually able to make "an over-glorified piece of sand, much smaller than your little fingernail," to do something useful. To do anything you like.

1 members found this post helpful.

As I had been exposed to Web-Application development for longer than any living thing should be, I have become addicted to logging. Tracing a problem to its true origin is made in several ways, but until further notice, I will not take the cure.

As far as I remember, there had *not once* been a cast missing, when the warning appeared in my compiler output.

In my case, it invariably meant that I had carelessly used the wrong variable name.

That or I have really tried to assign incompatible variables, because one of the data-types was – truly – ill-chosen. It is funny, how this error does no longer occur with Ruby, but is replaced by others of more arbitrary type and consequence ... Duck-typing adds a lot of hilarity where other programming languages are just grim.

I can see how you would use a git reset followed by a new commit to combine prior commits into a single entry but how do you do it with "rebase"? Did you misspeak and intend to say "reset", or am I missing a trick with "rebase"?

See //www.git-scm.com/docs/git-rebase#_interactive_mode

This is something that it's good to practice with on an unimportant/duplicated repository - the process is obvious when one understands it, but might be intimidating the first few times, so it's good to have the reassurance of being able to experiment with it not mattering if something screws up.

1 members found this post helpful.

Ahh, thanks.

I've only ever used a non-interactive rebase. I'll have to give this a shot.

The rebase command is used to interactively merge a number of commits into a single one. I did not use the wrong word. Just carefully read the docs and then try it. It's quite easy to do (correctly).

And – as it happens – I always "do 'git'" from the command-line. This keeps me from having to puzzle-out the "convenient" features of this-or-that editor. By now, "it is a reflex."

1 members found this post helpful.

rebase/cherry-pick/merge*is/are the most confusing part of a version control system. It helps to combine two (or more) parallel code modifications into one single change. But it's much easier to do it wrong than right (this is my own experience in a group with many people working on the same codebase implementing many different features).

2 members found this post helpful.

I do use merge but I do not fool around with cherry-pick. There are plenty of aspects of git which are "well beyond my pay-grade."

Basically, I just do "a ton of in-progress commits," and then wrap all of them up into a single 'final' commit which I actually push public.

Every now and then, you simply "f!ck everything up," and what you want to do is: git reset --hard. Which is precisely what you do. Now you're miraculously teleported back to where you are once again on the diving board and you can decide what to do next. Older but wiser.

I use git for every project, even when there isn't any "external repository" and I never "push." What's priceless to me is that: "git doesn't need a server." (As I said: "Thanks, Linus! That's the second time you did something remarkable ...")