LTCD_070816.ISO

This commit is contained in:
Terry A. Davis authored and minexew committed 2018-09-08 21:45:20 +02:00
1 parent d14bbc24f9
commit 0e9364ff4c
506 files changed
+157705 -41812

No files matched your search

+25
View File
@@ -0,0 +1,25 @@
$WW,1$$FG,5$$TX+CX,"Proverbs"$$FG$
Writing your own code is more fun then modifying someone else's. Sadly, I heard 90% of programmers work on maintaining code. One good thing about looking at other people's code is it's a good way to learn -- you can learn what to and what NOT to do.
Code written by one person is less redundant than code written by a team because one person knows when he is reinventing the wheel. It is more vertical, meaning deeper levels of subroutines.
When working on other people's code, you tend to be defensive, using caution about uncertain items and this adds unnecessary code.
Documentation which is out-of-date is worse than no documentation. With LoseThos, I tried to keep documentation right by code.
If you call common low-level routines, there is a potential for huge added functionality with changes to the low level routines, benefitting everything. Imagine modifying a file choosing dialog.
Not all features are good to use. I've seen cases where people use macro functions ($FG,2$#define$FG$) to make C code look like C++ code. It becomes one-more layer you have to look-up to understand. An advantage of nonvertical coding is readibility. It is possible to get carried away with nonstandard library routines.
One mentor discouraged using abbreviations. One advantage of nonabreviated labels is there's no uncertainty on how to spell them. Typing is never what slows you down, except maybe at the command line. Uncertainty is what slow you down.
One mentor always put "temp" on the beginning of local variables -- "$FG,2$tempd$FG$" instead of just "$FG,2$d$FG$". The reason is probably for text searches. I've somewhat eliminated this need with the "whole label" search feature.
$LK,"Grep","MN:Grep"$() is my best friend. I use a wrapper function $LK,"F","MN:F"$().
It's easier to write a command-line interface than a GUI one and if it's for personal use, why not?
On a modern home computer, the only things which take significant memory are disk cache, graphics and sound. Code related items do not. If you had a million lines of code and stored an 8-byte value telling where each line was located, that would be 8 Meg. I have 2Gig, so that would be 0.4 %. Structures for classes and functions amount to nothing.
A home computer doesn't really need a big disk cache. How often do you listen to the same multimedia items more than once? If you have a server for a database, sure you need disk cache.