macOS Tips to break bad coding habits?

[mdatwood]

We have a ton of automation testing, but it can never possibly catch everything.

I do need to get better acquainted with test-driven software development though. As much of a PITA as it sounds, I think in the long run, its a good thing.

In terms of refactoring, we produce code diff's for our QA teams. It gives them an idea of testing coverage per lines of change. The real issue is not so much testing within the system itself, but all the external systems we connect with.

Tests don't catch everything, but that's the nature of software development. Most of the software I write is very iterative in nature so I'm always going back over code that's already written. Start with a simple idea then build an MVP release, repeat. This works for my current company because I'm writing software that doesn't exist and has very comparisons. Users need to see something before they start to realize other features they need.

External systems can be a pain to interface. What you need to do is isolate those interfaces from the rest of the system so that changes on either side do not break the other side. One system that I wrote pulls data in from many other systems (hardware call center management systems be exact - phone switches, predictive dialers, etc...) and I used a lot of techniques to isolate each system and version so that if one system feed changes it doesn't break the whole thing. The first version wasn't that robust, but over time and many refactorings it emerged

 

[mward333]

To the OP: I think that the best way to break bad programming habits is to suffer from your habits and then learn your lesson. In other words, once you do something really really stupid, if it causes you some pain, you are not likely to repeat it. Those of us who write tons and tons of code will also do stupid things from time to time, and we learn from our mistakes.

I tend to do the following:
Try to write something intelligent on paper first, before you ever touch a keyboard. There are many ways to do this, and it is extremely effective.
Use lots of helpful comments in the code.
Save the code all the time... I press "save" at least once per line.
Be smart about version control (whatever scheme you prefer).
Test your code constantly.
Test with many types of examples.
Test frequently.
Keep testing.
Be willing, as time permits, to rewrite your entire program. I find that, once I'm done with a large program, I have usually discovered a better way to do everything. So if I start over again from the very beginning, and rewrite the program again, my second version is much much better. It takes time, of course, but 80 percent of the time, my second version of the program is much much better (faster, less space, etc.) than my first version.

I hope that these are helpful tips.

There are lots of useful books lying around (I have dozens and dozens of good coding books, and I love to read them), but I won't put you to sleep with the titles on my bookshelf.....

Good luck to you!

 

[seepel]

To the OP: I think that the best way to break bad programming habits is to suffer from your habits and then learn your lesson. In other words, once you do something really really stupid, if it causes you some pain, you are not likely to repeat it. Those of us who write tons and tons of code will also do stupid things from time to time, and we learn from our mistakes.

I tend to do the following:
Try to write something intelligent on paper first, before you ever touch a keyboard. There are many ways to do this, and it is extremely effective.
Use lots of helpful comments in the code.
Save the code all the time... I press "save" at least once per line.
Be smart about version control (whatever scheme you prefer).
Test your code constantly.
Test with many types of examples.
Test frequently.
Keep testing.
Be willing, as time permits, to rewrite your entire program. I find that, once I'm done with a large program, I have usually discovered a better way to do everything. So if I start over again from the very beginning, and rewrite the program again, my second version is much much better. It takes time, of course, but 80 percent of the time, my second version of the program is much much better (faster, less space, etc.) than my first version.

I hope that these are helpful tips.

There are lots of useful books lying around (I have dozens and dozens of good coding books, and I love to read them), but I won't put you to sleep with the titles on my bookshelf.....

Good luck to you!

I second and third this. I not only save, but compile after about every line of code, and compile+run after every five lines. Command+b and Command+Enter are my best friends (build and build+run in XCode).

 

[mward333]

I second and third this. I not only save, but compile after about every line of code, and compile+run after every five lines. Command+b and Command+Enter are my best friends (build and build+run in XCode).

Yes, I meant to say that explicitly, but I didn't put it into my post. I compile all the time too. Every time that my code should compile, I DO compile it, and check it, and check it, and check it. I'm very careful. When I'm working with a student on a project, I think it amazes them that I'm so careful, but my code rarely fails on me. I'm very happy with my relationship with gcc, perl, Maple, etc. I don't know how people conducted scientific research before they had a trusty computer by their side! My hand with pencil and paper is too unreliable. I love to check my theorems with the computer.

I'm a mathematician, obviously, but these things should be the same for ANYONE who is coding.

Main point: It is important to be careful, to save often, to compile often, and to check check check check. Reckless and fast coding is painful, and it usually ends up costing much more time in the long run!

Again, good luck to the OP.

Thank you to user "seepel" for pointing out that I forgot to mention "compile, compile, compile" in my posting! I meant to say that too!

 

[Cromulent]

I found the article I referred too above if anyone is interested.

Consider using a Goto-Chain when leaving a function on error when using and releasing resources