I wonder how much of a pain it would be to make an app where you can move the editboxes/stuff around on the screen in C++/VB?
VB: 1 line
C++: I don't care to find out
Short programs probably aren't such a good indication of the usefulness of the language though. What VB does with that one line is not very impressive. Especially since it really depends on what you are doing. I mean, some things are really easy in assembly that would take a number of instructions in other languages. And technically, you can write everything in C/C++ on one line. (Just don't tell any of my instructors that I've suggested writing everything on one line.)
Oh, and don't worry about "learning code". I know what that's like. Come to think of it, it sometimes seems like all my code is "learning code".
As an example of how bad I was... (before I actually had lessons on "proper programming conventions")
- I always used line number, not labels
- I never used variable names with more than 1 letter
- Absolutely no whitespace that wasn't syntactically required
- I wrote an entire program (2000 lines of GWBASIC) where all the numeric stats where all stored in a binary packed string. This of course required memorizing the offset and length of all the data into the string. (String length: about 200) Here's a sample from the much clean up sequel (5300+ lines of QBASIC plus code for the 2 editors, but with up to 2 letters in a variable name! I was also starting to drop line numbers occasionally and added a space between some symbols):
5350 i = Int(CVDMBF(Mid$(b$, 39,
) / ((Asc(Mid$(b$, 63, 1)) + 1) * 5))
This stores your money/(5*level) into a temp variable
If Asc(Mid$(mo$, 160, 1)) <= Asc(Mid$(b$, 63, 1)) + 1 And Asc(Mid$(mo$, 161, 1)) >= Asc(Mid$(b$, 63, 1)) + 1 Then i = i - 1
This was used in a loop to find a random monster for you to fight. You had to be in a certain level range to fight certain monsters. It first found how many where available for you to fight and then randomly selected one.
- To save space, (tight memory constraints) I wrote as many commands on one line (less line numbers meant a few less bytes). The line often wrapped around the screen 3 times. I'd get as many of the 255 characters max on a line as possible unless I needed to break for a possible control flow change.
- I actually considered ways to make use of the last
23 BYTES of RAM.
- I never used any loop statement other than a FOR loop. (Yep. All Goto/Gosub
) ... and remember, line numbers.
- In a really early project I didn't know about inequality compares (I hadn't yet seen them and I was very young). Guess how I implemented the shop code so your money couldn't go negative. :lol: (For some reason, there was always a case I missed... :whistle: )
- many many sequential IF THENs
- no identation whatsoever (heck, it wasn't even possible in GWBasic)
- custom code to write directly to video memory for faster screen updates! (That got a little hairy but the speed increase was well worth it).
- and when I was really feeling nasty, I had assembly commands written in strings which could be called. (s$=chr$(0...255)+chr$(0...255)+chr$(0...255)+...) Executable strings made me happy. (thumbsup)
- And for good measure, I occasionally encrypted stuff (both data and code) or relied on compiler/interpreter errors for things to work, when possible.
Needless to say, I didn't get along with my first computer teacher. :heh:
The funny thing is, my programs had less bugs than hers. Plus I was always somehow able to fix mine faster. Oh, and that sequel game, I rewrote it once to make all the code look nice and consequently introduced about 100 bugs. Before the rewrite, there were no known bugs. (But hey, it was a game, I "tested" it often. Every piece I wrote got tested almost right away).
Oh hey, and if you want to know ways of making C/C++ code unreadable, well that's even easier! Mmmm, Circularily dependent #defines in multiple include files with a complicated include hierarchy. The file does something different every time you include it. It depends on the number of times it eventually gets included in the hierarchy. :blink: And let's not forget languages that only read the first, say 8 characters of a variable name. MyBigVarNumber, MyBigVarPointer, MyBigVarString all refer to the same variable, but that doesn't stop you from calling it something different every time you refer to it.
Oh and try for variable names like nn, nm, mn, mm. They are really hard to distinguish with certain fonts.
Oh, and be sure to #define certain command to really be something else completely unrelated and also make sure all your subroutines have hidden side effects that aren't easily guessed. Half truths are harder to track down than complete lies.
I guess I could go on, but I've already rambled excessively. :blush:
