Author Topic: Considering learning programming  (Read 882 times)

NFITC1

  • No life
  • *
  • Posts: 2874
  • Karma: 72
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Re: Considering learning programming
« Reply #25 on: 2019-02-12 16:12:51 »
This is a very common C gotcha (attempting to dereference podhd via &(podhd->line6) is undefined behavior if podhd is NULL. The check for NULL belongs before the attempt at dereferencing podhd and really any C programmer will know that. There's nothing wrong with the "second check" except that it's misplaced, and most good compiler's (gcc, for example) will optimize it away as the attempt to dereference podhd in the previous line will let the compiler know (mistakenly) that podhd cannot be NULL.

Simple solution, check for NULL before you dereference pointers. These sorts of things are more of a hassle when you're learning than later on when you've developed good habits w.r.t NULL handling (responsible for about 90% of C's "gotchas"). Being able to propogate constraints like this and letting the compiler (or instructing it with __builtin_unreachable) optimize away unnecessary works/checks is another factor that contributes to the performance advantage well written C code enjoys over most other compiled languages.

This is not unique to C. This is poor program planning and a violation of the Fail Fast programming convention which can result in runtime errors. Most, but not all, IDEs in more modern languages will detect this and some won't even let you compile. That's with pretty strict options as it will just throw a nullpointerexception (or that language's equivalent) which might be caught outside the method.

The actual solution is always check all your arguments' states before performing any logic on them. Almost all programming errors are the result of NOT performing these checks and handling bad states correctly. The others result from creating massively long methods that try to do too much so no human can keep track of what it's actually doing and it ends up contradicting itself or another method. These errors are universal to all programming.

MysticLord

  • Fast newbie
  • *
  • Posts: 22
  • Karma: 5
    • View Profile
    • SaGa Frontier Research Board
Re: Considering learning programming
« Reply #26 on: 2019-02-12 21:11:15 »
Whatever language you choose is capable of making editors and writing scripts to automate boring tasks.  It's really up to you, your favored operating system, the OS your users use, and - if you want to modify other people's editors - the language those authors used.  This limits you to C-like languages: C, C++, C#, Java, and Python to a degree.  Hence why you should learn one of them as your primary language, and later master a language like C (one of the hardest, but still a very small language and standard library compared to the others).  Once you do this you can easily teach yourself any other language in the family.  Progression for most college students is Python/VB.NET -> Java/C# -> C/C++.

Don't fret much for Linux users, most Lusers can figure out how to run anything given enough time.

Last piece of advice is learn the basics of git useage - add, commit, push, git ignore, and how to make a repo - and set up at least private repos for all your projects.  This matters because:
1. Hard drives fail.
2. Sometimes you code yourself into a corner and can't figure out how you got something to work earlier.  Looking back on earlier revisions alleviates this problem.
3. It feels good looking back on how far you came.
4. I've heard employers like seeing them, but since I'm not employed in the field I can't say.

Bosola

  • Fire hazard!
  • No life
  • *
  • Posts: 1766
  • Karma: 15
    • View Profile
    • My YouTube Channel
Re: Considering learning programming
« Reply #27 on: 2019-02-14 12:48:54 »
@QuantumPencil - how do you feel about Rust?