On 02/16/18, Black Panther said the following...
On 02/16/18, tenser said the following...
Many of you are writing code in Free Pascal. Find a unit testing framework for it and learn how to use it well, then get into the habi
I didn't even know that was an option until I read this... I've looked
it up, and it seems that Lazarus already has a couple of options available. I'll be doing some looking into that. Thanks.
That's great! It forces a different way of programming, but once
you get the hang of it you'll wonder how you ever did things before.
of writing tests for your code. Also, start using a revision control system if you don't already and get into the habit of making lots of small commits.
Revision control I have been doing. On the other hand, I have a tendency make commits that are a lot larger, and contain many additions/changes.
I really should stop that...
It takes a while to get into the habit, but once you've got it down
it's handy. In general, you should structure the history of your commits
as if you were telling a story. Coupled with good commit messages,
you'll rarely run into the, "what the hell was I thinking six months
ago?!" thing.
Much of the, "I put a getc(); or readln; into my program so I can see what was happening at that point in the code" is for debugging purpos
I find myself doing that a lot. I'll have it writeln what is contained
in the variables to the screen, and then put a readln, so I can read it.
Hey, that's fine: I totally get it. Sometimes it's the best way. When
you're doing iterative development, it can make a lot of sense: you
write something, you get it to the point where you think it's more or
less doing what you want, you print some output so you can inspect
state at that point, and then you move on. It's not a BAD way to do
things, but there are other ways that are better (writing lots of unit
tests) if you can get your code into the shape that it admits that kind
of testing.
This is also handy because those tests are easily repeatable: You make
some change, and if you run the tests again and they all pass (and you've
got good test coverage) then you can move forward under the reasonable assumption that you haven't broken anything. On the other hand, if the
tests fail, then you've got something you can look at to help you
troubleshoot what went wrong. If you couple that with relatively small
commits, it's often fairly easy to find the problem.
I get it; I've been there too (I develop kernels for a living so you better believe I pepper code with a bunch of, `asm volatile("HLT;"::: in various places so I can figure out what's faulting and why). But
That has got to be an interesting and sometimes frustrating job. :)
Yeah, it's interesting but it can be really frustrating. Here's an example
of something I found recently that was a pain: I had a small microhypervisor we're investigating that came out of a research project. The code is sort
of like the Fisher Price, "Grad Student's First C++ Program": overusing esoteric language features because they're cool; that kind of thing. Anyway, most of the time these things start by having a bootloader jump to some
known entry point that you hand-code in assembler: this gets paging enabled, gets the machine into 64-bit mode (this is an x86_64 platform), sets up the language runtime environment and then jumps to the high-level language entry point (e.g., the `main` function). Only the thing was boot-looping due to an unhandled fault in the early startup code. Through judicious use of the HLT instruction through assembler, I was able to run it under QEMU and a debugger and find that it was dying on an invalid instruction (a left-shift that preserves condition codes; introduced in Haswell, but I was running it on
an older microarchitecture). Oops. I changed the compiler flags to emit code for an older platform (core2) and it magically started working. Because my changes were minimal, I could just `git checkout file.cpp` to revert them.
Yay revision control.
getting into the unit testing discipline gets rid of the need for mos of it, and the revision control system makes it easy to back that stu out and get back to a known-working state.
Do you think using something like github would be a good idea for
revision control? Or do you think just copies on the hard drive, and figuring out which .PAS file is which, would be sufficient? :)
Sure, github is fine, but github is a repository hosting service. For a
SCM like git, which is a *distributed* version control system, you've
already got a repository locally. Github is great because it lets you
publish your work and collaborate with other programmers, but it's not necessary. The work flow is usually that you clone the repo on github
into a local repo, edit, commit, amend, and generally make changes to your local clone, then push those to a branch on github (or, if it's a personal project, you can push to your own `master` branch).
As far as specific revision control systems, `git` is quickly becoming
a standard. Mercurial is also nice; stay away from Subversion, Perforce,
CVS, RCS, SCCS, or any of the proprietary systems (Source Safe or whatever Microsoft's offering is). Such centralized or file-based VCS's are going
the way of the dodo.
Hope that helps!
It really does. Thank you.
Great! I'm happy to hear it.
--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: ACiD Telnet HQ / blackflag.acid.org (21:1/112)