• Proposal to reduce the memory consumption of images in Mozilla

  When you run Mozilla or Firefox and load a web page with images, it stores the uncompressed images as pixmaps in the X server. In particular, it seems to maintain live pixmaps for all the images in all the tabs that you have open; even if a tab is not visible, the images will be in your X server's memory.

  When you exit Firefox, the X server is smart enough to return this memory to the kernel.

  Web pages use compressed images, of course, to reduce download time. These images will likely take up a lot of space when uncompressed.

  For example, I have a directory with about 4.3 MB of JPEG images:

  $ du -s jpegs
  4372    jpegs

  If I uncompress those images, they balloon in size to about 67 MB:

  $ mkdir uncompressed
  $ for i in jpegs/*.jpg; do convert $i uncompressed/`basename $i .jpg`.ppm; done
  $ du -s uncompressed
  67172   uncompressed

  Let's see what happens once we load those images in Firefox. I created a simple HTML page with <img> tags for each of the files in my jpegs directory, so that Firefox would load all the images, uncompress them, turn the uncompressed data into a format suitable for X pixmaps, and ship the pixmaps to the server.

  To take some rough numbers on memory consumption, I used ps and the fabulous xrestop. Xrestop is like the usual top command, but it will tell you how many resources each client is using in the X server. In particular, one of the columns in xrestop tells you how much memory a client is using for pixmaps.

  This is output of ps and xrestop for a newly-started Firefox:

  ps:
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  federico 27833 20.7  4.6  55080 24136 pts/0    Sl   11:12   0:01 /opt/MozillaFirefox/lib/firefox-bin
  
  xrestop:
  res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
  4400000    87   53    1   29   30      415K      4K    420K   ?   Mozilla Firefox

  So, our base numbers are 24 MB resident on the client, and 415 KB of pixmaps in the server. Remember, that's for a newly-started Firefox.

  After loading my page full of JPEGs, we get this:

  ps:
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  federico 27833  4.7  5.0  56544 26172 pts/0    Sl   11:12   0:05 /opt/MozillaFirefox/lib/firefox-bin
  
  xrestop:
  res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
  4400000    88   71    1   73   31    95327K      5K  95332K   ?   Mozilla Firefox 

  Woah! The Firefox process grew its resident size by only 2 MB, but it created about 95 MB of pixmaps in the server. Why is this larger than the 67 MB of uncompressed image data that we got before? Who knows — probably the pixmaps require more memory for padding than the raw RGB data.

  Remember that our compressed images occupied about 4.3 MB? The Firefox process only grew by about 2 MB: this indicates that it doesn't keep the compressed data in memory once it has shipped the images to the server. That's a good thing: keep a single copy the image data.

  Then, I opened a new empty tab in Firefox, and closed the tab with the images:

  ps:
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  federico 27833  2.9  5.0  56544 26200 pts/0    Sl   11:12   0:06 /opt/MozillaFirefox/lib/firefox-bin
  
  xrestop:
  res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
  4400000    91   83    1   46   32    24988K      5K  24994K   ?   Mozilla Firefox

  The Firefox process grew its resident size by a bit, but it didn't grow its total virtual size. So, no worries on that front. However, it left about 24.9 MB of pixmaps in the server. Why is that? Is it part of the browser's cache? Or is it leaking pixmaps?

  Let's find out. I loaded the page with JPEGs again:

  ps:
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  federico 27833  3.3  5.5  58568 28544 pts/0    Sl   11:12   0:09 /opt/MozillaFirefox/lib/firefox-bin
  
  xrestop:
  res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier
  4400000   105   89    1   78   38    95328K      6K  95334K   ?   Mozilla Firefox

  The process grew this time by about 2 MB in its total virtual size, and increased its resident size by about 2 MB. Note that it is slightly bigger than the first time we loaded the page with JPEGs. But that's only a little memory compared to what we have in the server, so let's not worry about it for now. Note that the server grew again to hold about 95 MB of pixmaps. This matches the value from our initial run, so we can be reasonably confident that Firefox is not leaking pixmaps in the X server. It just keeps them there as part of the browser cache.

  What have we learned so far?

  • Yes, uncompressed images are much larger than compressed ones.

  • Firefox doesn't keep more than copy of the images around, in either representation. That's good.

  • Firefox keeps the images for all the tabs that are open as uncompressed pixmaps in the X server. That's not horrible, as it has to keep the images somewhere.

  But can we do better? That is, can we keep only (or mostly only) the compressed images in memory, until we need to draw them on the screen?

  Proof of concept

  Let's summarize what we want to test:

  • If you must keep images in memory, keep them in compressed format ("as downloaded from the net"). What's the memory savings of doing this?

  • When you need to paint an image to the screen (i.e. when the user scrolls to make the image visible), uncompress it on the fly. Does this lead to bad performance?

  To answer the part about memory savings, we just have to compare the size of the compressed and the uncompressed images. That's easy.

  To answer the performance question, we have to run a program with that behavior and scroll around its window to get an intuitive feel of how it performs. If needed, we can add instrumentation or profile the program to get hard numbers.

  The program in question is very simple: moz-images.cs. Download it and look at the comments in the top to see how to compile it. You run the program like this:

  mono moz-images.exe /directory/full/of/images mode 

  The mode option can be --server, --client, or --compressed. These do the following:

  • --server: Loads all the images in advance, creates uncompressed X pixmaps for them, frees the compressed data. When it has to repaint, it just copies from the appropriate pixmap to the window.

  • --client: Loads all the images in advance, keeps them uncompressed in the client as GdkPixbuf objects. When it has to repaint, it sends the appropriate area from a pixbuf to the X server for painting.

  • --compressed: This is the interesting one. Loads the images, but keeps them in their original compressed form in memory. When it has to repaint, it uncompresses the images that would be visible on the screen, and sends them to the X server. When you scroll so that an image is no longer visible, the program frees the uncompressed data for that image; it will decompress the original data again as needed.

  I used ps and xrestop for each case to get a table of results. To ensure that all the images were paged into memory, I scrolled up and down the window a few times for each case, and then ran ps and xrestop.

  

  Mode	Resident size	Pixmaps in X server	Total size	Performance
  --server	15380 KB	92683 KB	108063 KB	(1)
  --client	85324 KB	384 KB	85708 KB	(2)
  --compressed	19204 KB	384 KB	19588 KB	(3)

  1. With --server, the program took a long time to start up as my machine started swapping to make room for the overgrown X server process. The second run was faster, because there was room in RAM already. It still took a little while to uncompress all the images in advance (between one and two seconds). Scrolling was super-fast, as expected, since all the pixmaps were already in RAM and in the server. Note that we use relatively little memory in the client, but a lot of memory in the server. The cumulative usage is 108063 KB.

  2. With --client, the program was reasonably fast to start up, though there was room in RAM already. It still took a little while to uncompress all the images in advance. Scrolling was super-fast and I could not see a difference between this and --server. This is to be expected as the program was running on the same machine as the X server. We use very little memory in the server indeed, but a lot in the client. The cumulative usage is 85708 KB.

  3. With --compressed, the program started up faster than in the other runs, since it doesn't have to uncompress all the images in advance. Scrolling is a bit jerky if you yank the scrollbar's thumb up and down very quickly. The jerkiness is barely noticeable if you use the scroll wheel or the scrollbar's arrows at about the same rate as you would use while reading a web page. Note that we use reasonably little memory in the client, and very little memory in the server. The cumulative usage is 19588 KB.

     Also, compare the resident size of --compressed with that of --server. In the former, we use 19204 KB; in the latter, we use 15380 KB. The difference is about 4 MB. This matches our initial measurement of 4.3 MB for the compressed JPEGs.

  Summary

  For Firefox, keeping the compressed, as-downloaded images in the client could reduce memory consumption a lot. My program is a proof of concept and doesn't do anything fancy to reduce the little jerkiness that results from uncompressing the images on the fly. Firefox could get much fancier; it could probably uncompress the images that are adjacent to the viewable area, in advance, while you are still reading what is in the viewable area. This would be equivalent to read-ahead for hard disks.

  For the proof-of-concept program, we reduced the cumulative memory usage from 108063 KB to 19588 KB — that is, a factor of 5.5.

1. Java (16738 projects)
2. C++ (16731 projects)
3. C (15934 projects)
4. PHP (12175 projects)
5. Perl (6209 projects)
6. Python (4542 projects)
7. C# (2892 projects)
8. JavaScript (2779 projects)
9. Visual Basic (2192 projects)
10. Delphi/Kylix (1926 projects)
11. Unix Shell (1845 projects)
12. Assembly (1608 projects)
13. PL/SQL (1145 projects)

The next big thing since sliced bread - Ruby - is at a whopping 400 projects. Much less than Objective C (739), but more than Lisp (323) and even Pascal (357)! Java really needs to worry.

无论是刀架或者上鞋或者全套都可以啊，快快砸过来吧... 当然如果愿意把上鞋换成S-Lab我会更高兴的。

Seba韩国出售高端版本 + Viper新款SideWainder刀架(前几天的blog有介绍，自己去找找):

我只能说这篇文章太牛x了，Tom's hardware的编辑们太牛x了，我不知道写这篇文章要多久，我只知道看这篇文章要很久很久。

The Mother of All CPU Charts 2005/2006

文章我不贴了，自己去看吧。把重要的图表贴过来，因为实在是太喜欢这些图表了。

很喜欢最上面的搭扣设计。

上个礼拜妖猪过生日，杀到我家来做饭吃，太ws了。弄的我家里一塌糊涂啊一群贱人吃完就跑了都不帮忙收拾一下，老白痛苦的打扫厨房+洗碗还一边喊着要去死，人间惨剧。

wd+zn+yz在视察饭桌:





yz做出了有生以来最有领袖气质的一张照片:



可爱的菜们，一个小时之后被我们吃了:





zt一如既往的yd:



这个时候，老白出现了，摆出了自其出生以来最帅的一个pose, 当然新剪的头发功劳也很大:



wd看到老白耍帅愤怒鸟，跑来抢镜头:



哈哈哈哈地主大笑三声，你跟我抢镜头？太嫩了。镜头遂被地主抢了回去，然后地主摆出了自娘胎出来以后最纯洁滴一个表情:



wd也怒了，开始喷口水:



这时候班长大人驾到，有小马哥风范啊... 拜:



小马哥做事总是出人意表:



好像有点ws... 但是再ws也不会有zt ws了。zt做出了本年度最ws的事情:



最后通过zt的带动，大家也积极的ws起来，实现了计算机10班元老们的共同ws~~~





好像还是挺好吃的...



传说中的炒面...

http://wired-vig.wired.com/news/business/0,1367,69585,00.html?tw=rss.TOP
由于在乡村维持生活水准的费用要远远低于大都市，所以美国现在出现了一种新的外包形式：把分公司放到乡村去。在纽约雇佣一位IT专家每小时需要花去100美元，而在乡村这笔费用就下降到了35到40美元左右。虽然这仍然比在印度或者其他外包地点雇佣员工的费用高，但是由于是在自己的国家还是会得到许多额外的好处，比如同时区以及法律上的帮助。

如果人民币升值，我想来中国外包会越来越不划算，除非是研发放到中国，这样核心技术也许会进来吧。在本国乡村建立外包公司的思路挺好的，也许能搬到中国来实践。在中国乡村的生活成本要远远低于上海这种城市，只是中国的乡村基础设施太弱了，和美国相比差距有点儿大，估计没人愿意去。

工作的一定要看，这样你就知道怎样才不会被开除了，因为你写的代码没人看得懂，只有你自己能够维护。公司不高薪留你，留谁啊，哈哈。在大学里面念CS的要看，这样你就知道怎么样把同学那里copy过来的程序改头换面成自己都看不懂的另外一个程序交上去了，居家必备。

http://thc.org/root/phun/unmaintain.html

How To Write Unmaintainable Code

Ensure a job for life ;-)

Roedy Green
Canadian Mind Products

---

Introduction

Never ascribe to malice, that which can be explained by incompetence.
- Napoleon

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!

You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored.

General Principles

Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.

He views your code through a toilet paper tube. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything.

Programmers are lulled into complacency by conventions. By every once in a while, by subtly violating convention, you force him to read every line of your code with a magnifying glass.

You might get the idea that every language feature makes code unmaintainable -- not so, only if properly misused.

Naming

"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean - neither more nor less."
- Lewis Carroll -- Through the Looking Glass, Chapter 6

Much of the skill in writing unmaintainable code is the art of naming variables and methods. They don't matter at all to the compiler. That gives you huge latitude to use them to befuddle the maintenance programmer.

New Uses For Names For Baby

Buy a copy of a baby naming book and you'll never be at a loss for variable names. Fred is a wonderful name, and easy to type. If you're looking for easy-to-type variable names, try adsf or aoeu if you type with a DSK keyboard.

Single Letter Variable Names

If you call your variables a, b, c, then it will be impossible to search for instances of them using a simple text editor. Further, nobody will be able to guess what they are for. If anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables, namely replacing them with ii, jj and kk, warn them about what the Spanish Inquisition did to heretics.

Creative Miss-spelling

If you must use descriptive variable and function names, misspell them. By misspelling in some function and variable names, and spelling it correctly in others (such as SetPintleOpening SetPintalClosing) we effectively negate the use of grep or IDE search techniques. It works amazingly well. Add an international flavor by spelling tory or tori in different theatres/theaters.

Be Abstract

In naming functions and variables, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method.

A.C.R.O.N.Y.M.S.

Use acronyms to keep the code terse. Real men never define acronyms; they understand them genetically.

Thesaurus Surrogatisation

To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean "write to a file", "put ink on paper" and "display on the screen"). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be an unprofessional breach of the structured design principle of information hiding.

Use Plural Forms From Other Languages

A VMS script kept track of the "statii" returned from various "Vaxen". Esperanto , Klingon and Hobbitese qualify as languages for these purposes. For pseudo-Esperanto pluraloj, add oj. You will be doing your part toward world peace.

CapiTaliSaTion

Randomly capitalize the first letter of a syllable in the middle of a word. For example ComputeRasterHistoGram().

Reuse Names

Wherever the rules of the language permit, give classes, constructors, methods, member variables, parameters and local variables the same names. For extra points, reuse local variable names inside {} blocks. The goal is to force the maintenance programmer to carefully examine the scope of every instance. In particular, in Java, make ordinary methods masquerade as constructors.

Åccented Letters

Use accented characters on variable names. E.g.
typedef struct { int i; } ínt;
where the second ínt's í is actually i-acute. With only a simple text editor, it's nearly impossible to distinguish the slant of the accent mark.

Exploit Compiler Name Length Limits

If the compiler will only distinguish the first, say, 8 characters of names, then vary the endings e.g. var_unit_update() in one case and var_unit_setup() in another. The compiler will treat both as var_unit.

Underscore, a Friend Indeed

Use _ and __ as identifiers.

Mix Languages

Randomly intersperse two languages (human or computer). If your boss insists you use his language, tell him you can organise your thoughts better in your own language, or, if that does not work, allege linguistic discrimination and threaten to sue your employers for a vast sum.

Extended ASCII

Extended ASCII characters are perfectly valid as variable names, including ß, Ð, and ñ characters. They are almost impossible to type without copying/pasting in a simple text editor.

Names From Other Languages

Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.

Names From Mathematics

Choose variable names that masquerade as mathematical operators, e.g.:
openParen = (slash + asterix) / equals;

Bedazzling Names

Choose variable names with irrelevant emotional connotation. e.g.:
marypoppins = (superman + starship) / god;
This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.

Rename and Reuse

This trick works especially well in Ada, a language immune to many of the standard obfuscation techniques. The people who originally named all the objects and packages you use were morons. Rather than try to convince them to change, just use renames and subtypes to rename everything to names of your own devising. Make sure to leave a few references to the old names in, as a trap for the unwary.

When To Use i

Never use i for the innermost loop variable. Use anything but. Use i liberally for any other purpose especially for non-int variables. Similarly use n as a loop index.

Conventions Schmentions

Ignore the Sun Java Coding Conventions, after all, Sun does. Fortunately, the compiler won't tattle when you violate them. The goal is to come up with names that differ subtlely only in case. If you are forced to use the capitalisation conventions, you can still subvert wherever the choice is ambigous, e.g. use bothinputFilename and inputfileName. Invent your own hopelessly complex naming conventions, then berate everyone else for not following them.

Lower Case l Looks a Lot Like the Digit 1

Use lower case l to indicate long constants. e.g. 10l is more likely to be mistaken for 101 that 10L is. Ban any fonts that clearly disambiguate uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]}. Be creative.

Reuse of Global Names as Private

Declare a global array in module A, and a private one of the same name in the header file for module B, so that it appears that it's the global array you are using in module B, but it isn't. Make no reference in the comments to this duplication.

Recycling Revisited

Use scoping as confusingly as possible by recycling variable names in contradictory ways. For example, suppose you have global variables A and B, and functions foo and bar. If you know that variable A will be regularly passed to foo and B to bar, make sure to define the functions as function foo(B) and function bar(A) so that inside the functions A will always be referred to as B and vice versa. With more functions and globals, you can create vast confusing webs of mutually contradictory uses of the same names.

Recycle Your Variables

Wherever scope rules permit, reuse existing unrelated variable names. Similarly, use the same temporary variable for two unrelated purposes (purporting to save stack slots). For a fiendish variant, morph the variable, for example, assign a value to a variable at the top of a very long method, and then somewhere in the middle, change the meaning of the variable in a subtle way, such as converting it from a 0-based coordinate to a 1-based coordinate. Be certain not to document this change in meaning.

Cd wrttn wtht vwls s mch trsr

When using abbreviations inside variable or method names, break the boredom with several variants for the same word, and even spell it out longhand once in while. This helps defeat those lazy bums who use text search to understand only some aspect of your program. Consider variant spellings as a variant on the ploy, e.g. mixing International colour, with American color and dude-speak kulerz. If you spell out names in full, there is only one possible way to spell each name. These are too easy for the maintenance programmer to remember. Because there are so many different ways to abbreviate a word, with abbreviations, you can have several different variables that all have the same apparent purpose. As an added bonus, the maintenance programmer might not even notice they are separate variables.

Misleading names

Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.

m_

a naming convention from the world of C++ is the use of "m_" in front of members. This is supposed to help you tell them apart from methods, so long as you forget that "method" also starts with the letter "m".

o_apple obj_apple

Use an "o" or "obj" prefix for each instance of the class to show that you're thinking of the big, polymorphic picture.

Hungarian Notation

Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:
Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.

Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.

Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!

Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.

Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table's primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!

Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:

• a single assignment statement carries 14 pieces of type and name information.
• a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.
• Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.
• It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can't see the start and end of each block on screen simultaneously.

Hungarian Notation Revisited

One followon trick in the Hungarian notation is "change the type of a variable but leave the variable name unchanged". This is almost invariably done in windows apps with the migration from Win16 :- WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam) to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam) where the w values hint that they are words, but they really refer to longs. The real value of this approach comes clear with the Win64 migration, when the parameters will be 64 bits wide, but the old "w" and "l" prefixes will remain forever.

Reduce, Reuse, Recycle

If you have to define a structure to hold data for callbacks, always call the structure PRIVDATA. Every module can define it's own PRIVDATA. In VC++, this has the advantage of confusing the debugger so that if you have a PRIVDATA variable and try to expand it in the watch window, it doesn't know which PRIVDATA you mean, so it just picks one.

Obscure film references

Use constant names like LancelotsFavouriteColour instead of blue and assign it hex value of 04FB. The color looks identical to pure blue on the screen, and a maintenance programmer would have to work out 0204FB (or use some graphic tool) to know what it looks like. Only someone intimately familiar with Monty Python and the Holy Grail would know that Lancelot's favorite color was blue. If a maintenance programmer can't quote entire Monty Python movies from memory, he or she has no business being a programmer.

Camouflage

The longer it takes for a bug to surface, the harder it is to find.
- Roedy Green

Much of the skill in writing unmaintainable code is the art of camouflage, hiding things, or making things appear to be what they are not. Many depend on the fact the compiler is more capable at making fine distinctions than either the human eye or the text editor. Here are some of the best camouflaging techniques.

Code That Masquerades As Comments and Vice Versa

Include sections of code that is commented out but at first glance does not appear to be.
for(j=0; j<array_len; j+=8)
{
total += array[j+0 ];
total += array[j+1 ];
total += array[j+2 ]; /* Main body of
total += array[j+3]; * loop is unrolled
total += array[j+4]; * for greater speed.
total += array[j+5]; */
total += array[j+6 ];
total += array[j+7 ];
}
Without the colour coding would you notice that three lines of code are commented out?

namespaces

Struct/union and typedef struct/union are different name spaces in C (not in C++). Use the same name in both name spaces for structures or unions. Make them, if possible, nearly compatible.
typedef struct {
char* pTr;
size_t lEn;
} snafu;

struct snafu {
unsigned cNt
char* pTr;
size_t lEn;
} A;


Hide Macro Definitions

Hide macro definitions in amongst rubbish comments. The programmer will get bored and not finish reading the comments thus never discover the macro. Ensure that the macro replaces what looks like a perfectly legitimate assignment with some bizarre operation, a simple example:
#define a=b a=0-b

Look Busy

use define statements to make made up functions that simply comment out their arguments, e.g.:
#define fastcopy(x,y,z) /*xyz*/
...
fastcopy(array1, array2, size); /* does nothing */

Use Continuation to hide variables

Instead of using
#define local_var xy_z
break up "xy_z" onto two lines:
#define local_var xy\
_z // local_var OK
That way a global search for xy_z will come up with nothing for that file. To the C preprocessor, the "\" at the end of the line means glue this line to the next one.

Arbitrary Names That Masquerade as Keywords

When documenting, and you need an arbitrary name to represent a filename use "file ". Never use an obviously arbitrary name like "Charlie.dat" or "Frodo.txt". In general, in your examples, use arbitrary names that sound as much like reserved keywords as possible. For example, good names for parameters or variables would be"bank", "blank", "class", "const ", "constant", "input", "key", "keyword", "kind", "output", "parameter""parm", "system", "type", "value", "var" and "variable ". If you use actual reserved words for your arbitrary names, which would be rejected by your command processor or compiler, so much the better. If you do this well, the users will be hopelessly confused between reserved keywords and arbitrary names in your example, but you can look innocent, claiming you did it to help them associate the appropriate purpose with each variable.

Code Names Must Not Match Screen Names

Choose your variable names to have absolutely no relation to the labels used when such variables are displayed on the screen. E.g. on the screen label the field "Postal Code" but in the code call the associated variable "zip".

Don't Change Names

Instead of globally renaming to bring two sections of code into sync, use multiple TYPEDEFs of the same symbol.

How to Hide Forbidden Globals

Since global variables are "evil", define a structure to hold all the things you'd put in globals. Call it something clever like EverythingYoullEverNeed. Make all functions take a pointer to this structure (call it handle to confuse things more). This gives the impression that you're not using global variables, you're accessing everything through a "handle". Then declare one statically so that all the code is using the same copy anyway.

Hide Instances With Synonyms

Maintenance programmers, in order to see if they'll be any cascading effects to a change they make, do a global search for the variables named. This can be defeated by this simple expedient of having synonyms, such as
#define xxx global_var // in file std.h
#define xy_z xxx // in file ..\other\substd.h
#define local_var xy_z // in file ..\codestd\inst.h
These defs should be scattered through different include-files. They are especially effective if the include-files are located in different directories. The other technique is to reuse a name in every scope. The compiler can tell them apart, but a simple minded text searcher cannot. Unfortunately SCIDs in the coming decade will make this simple technique impossible. since the editor understands the scope rules just as well as the compiler.

Long Similar Variable Names

Use very long variable names or class names that differ from each other by only one character, or only in upper/lower case. An ideal variable name pair is swimmer and swimner. Exploit the failure of most fonts to clearly discriminate between ilI1| or oO08 with identifier pairs like parselnt and parseInt or D0Calc and DOCalc. l is an exceptionally fine choice for a variable name since it will, to the casual glance, masquerade as the constant 1. In many fonts rn looks like an m. So how about a variable swirnrner. Create variable names that differ from each other only in case e.g. HashTable and Hashtable.

Similar-Sounding Similar-Looking Variable Names

Although we have one variable named xy_z, there's certainly no reason not to have many other variables with similar names, such as xy_Z, xy__z, _xy_z, _xyz, XY_Z, xY_z, and Xy_z.

Variables that resemble others except for capitalization and underlines have the advantage of confounding those who like remembering names by sound or letter-spelling, rather than by exact representations.

Overload and Bewilder

In C++, overload library functions by using #define. That way it looks like you are using a familiar library function where in actuality you are using something totally different.

Choosing The Best Overload Operator

In C++, overload +,-,*,/ to do things totally unrelated to addition, subtraction etc. After all, if the Stroustroup can use the shift operator to do I/O, why should you not be equally creative? If you overload +, make sure you do it in a way that i = i + 5; has a totally different meaning from i += 5; Here is an example of elevating overloading operator obfuscation to a high art. Overload the '!' operator for a class, but have the overload have nothing to do with inverting or negating. Make it return an integer. Then, in order to get a logical value for it, you must use '! !'. However, this inverts the logic, so [drum roll] you must use '! ! !'. Don't confuse the ! operator, which returns a boolean 0 or 1, with the ~ bitwise logical negation operator.

Overload new

Overload the "new" operator - much more dangerous than overloading the +-/*. This can cause total havoc if overloaded to do something different from it's original function (but vital to the object's function so it's very difficult to change). This should ensure users trying to create a dynamic instance get really stumped. You can combine this with the case sensitivity trickalso have a member function, and variable called "New".

#define

#define in C++ deserves an entire essay on its own to explore its rich possibilities for obfuscation. Use lower case #define variables so they masquerade as ordinary variables. Never use parameters to your preprocessor functions. Do everything with global #defines. One of the most imaginative uses of the preprocessor I have heard of was requiring five passes through CPP before the code was ready to compile. Through clever use of defines and ifdefs, a master of obfuscation can make header files declare different things depending on how many times they are included. This becomes especially interesting when one header is included in another header. Here is a particularly devious example:
#ifndef DONE

#ifdef TWICE

// put stuff here to declare 3rd time around
void g(char* str);
#define DONE

#else // TWICE
#ifdef ONCE

// put stuff here to declare 2nd time around
void g(void* str);
#define TWICE

#else // ONCE

// put stuff here to declare 1st time around
void g(std::string str);
#define ONCE

#endif // ONCE
#endif // TWICE
#endif // DONE
This one gets fun when passing g() a char*, because a different version of g() will be called depending on how many times the header was included.

Compiler Directives

Compiler directives were designed with the express purpose of making the same code behave completely differently. Turn the boolean short-circuiting directive on and off repeatedly and vigourously, as well as the long strings directive.

Documentation

Any fool can tell the truth, but it requires a man of some sense to know how to lie well.
- Samuel Butler (1835 - 1902)

Incorrect documentation is often worse than no documentation.
- Bertrand Meyer

Since the computer ignores comments and documentation, you can lie outrageously and do everything in your power to befuddle the poor maintenance programmer.

Lie in the comments

You don't have to actively lie, just fail to keep comments as up to date with the code.

Document the obvious

Pepper the code with comments like /* add 1 to i */ however, never document wooly stuff like the overall purpose of the package or method.

Document How Not Why

Document only the details of what a program does, not what it is attempting to accomplish. That way, if there is a bug, the fixer will have no clue what the code should be doing.

Avoid Documenting the "Obvious"

If, for example, you were writing an airline reservation system, make sure there are at least 25 places in the code that need to be modified if you were to add another airline. Never document where they are. People who come after you have no business modifying your code without thoroughly understanding every line of it.

On the Proper Use Of Documentation Templates

Consider function documentation prototypes used to allow automated documentation of the code. These prototypes should be copied from one function (or method or class) to another, but never fill in the fields. If for some reason you are forced to fill in the fields make sure that all parameters are named the same for all functions, and all cautions are the same but of course not related to the current function at all.

On the Proper Use of Design Documents

When implementing a very complicated algorithm, use the classic software engineering principles of doing a sound design before beginning coding. Write an extremely detailed design document that describes each step in a very complicated algorithm. The more detailed this document is, the better.

In fact, the design doc should break the algorithm down into a hierarchy of structured steps, described in a hierarchy of auto-numbered individual paragraphs in the document. Use headings at least 5 deep. Make sure that when you are done, you have broken the structure down so completely that there are over 500 such auto-numbered paragraphs. For example, one paragraph might be(this is a real example)

1.2.4.6.3.13 - Display all impacts for activity where selected mitigations can apply (short pseudocode omitted).

then... (and this is the kicker) when you write the code, for each of these paragraphs you write a corresponding global function named:

Act1_2_4_6_3_13()
Do not document these functions. After all, that's what the design document is for!

Since the design doc is auto-numbered, it will be extremely difficult to keep it up to date with changes in the code (because the function names, of course, are static, not auto-numbered.) This isn't a problem for you because you will not try to keep the document up to date. In fact, do everything you can to destroy all traces of the document.

Those who come after you should only be able to find one or two contradictory, early drafts of the design document hidden on some dusty shelving in the back room near the dead 286 computers.

Units of Measure

Never document the units of measure of any variable, input, output or parameter. e.g. feet, metres, cartons. This is not so important in bean counting, but it is very important in engineering work. As a corollary, never document the units of measure of any conversion constants, or how the values were derived. It is mild cheating, but very effective, to salt the code with some incorrect units of measure in the comments. If you are feeling particularly malicious, make up your own unit of measure; name it after yourself or some obscure person and never define it. If somebody challenges you, tell them you did so that you could use integer rather than floating point arithmetic.

Gotchas

Never document gotchas in the code. If you suspect there may be a bug in a class, keep it to yourself. If you have ideas about how the code should be reorganised or rewritten, for heaven's sake, do not write them down. Remember the words of Thumper in the movie Bambi "If you can't say anything nice, don't say anything at all". What if the programmer who wrote that code saw your comments? What if the owner of the company saw them? What if a customer did? You could get yourself fired. An anonymous comment that says "This needs to be fixed!" can do wonders, especially if it's not clear what the comment refers to. Keep it vague, and nobody will feel personally criticised.

Documenting Variables

Never put a comment on a variable declaration. Facts about how the variable is used, its bounds, its legal values, its implied/displayed number of decimal points, its units of measure, its display format, its data entry rules (e.g. total fill, must enter), when its value can be trusted etc. should be gleaned from the procedural code. If your boss forces you to write comments, lard method bodies with them, but never comment a variable declaration, not even a temporary!

Disparage In the Comments

Discourage any attempt to use external maintenance contractors by peppering your code with insulting references to other leading software companies, especial anyone who might be contracted to do the work. e.g.:
/* The optimised inner loop.
This stuff is too clever for the dullard at Software Services Inc., who would
probably use 50 times as memory & time using the dumb routines in <math.h>.
*/
classclever_SSInc
{
.. .
}
If possible, put insulting stuff in syntactically significant parts of the code, as well as just the comments so that management will probably break the code if they try to sanitise it before sending it out for maintenance.

COMMENT AS IF IT WERE CØBØL ON PUNCH CARDS

Always refuse to accept advances in the development environment arena, especially SCIDs. Disbelieve rumors that all function and variable declarations are never more than one click away and always assume that code developed in Visual Studio 6.0 will be maintained by someone using edlin or vi. Insist on Draconian commenting rules to bury the source code proper.

Monty Python Comments

On a method called makeSnafucated insert only the JavaDoc /* make snafucated */. Never define what snafucated means anywhere. Only a fool does not already know, with complete certainty, what snafucated means. For classic examples of this technique, consult the Sun AWT JavaDOC.

Program Design

The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible.
- Roedy Green

The key to writing maintainable code is to specify each fact about the application in only one place. To change your mind, you need change it in only one place, and you are guaranteed the entire program will still work. Therefore, the key to writing unmaintainable code is to specify a fact over and over, in as many places as possible, in as many variant ways as possible. Happily, languages like Java go out of their way to make writing this sort of unmaintainable code easy. For example, it is almost impossible to change the type of a widely used variable because all the casts and conversion functions will no longer work, and the types of the associated temporary variables will no longer be appropriate. Further, if the variable is displayed on the screen, all the associated display and data entry code has to be tracked down and manually modified. The Algol family of languages which include C and Java treat storing data in an array, Hashtable, flat file and database with totally different syntax. In languages like Abundance, and to some extent Smalltalk, the syntax is identical; just the declaration changes. Take advantage of Java's ineptitude. Put data you know will grow too large for RAM, for now into an array. That way the maintenance programmer will have a horrendous task converting from array to file access later. Similarly place tiny files in databases so the maintenance programmer can have the fun of converting them to array access when it comes time to performance tune.

Java Casts

Java's casting scheme is a gift from the Gods. You can use it without guilt since the language requires it. Every time you retrieve an object from a Collection you must cast it back to its original type. Thus the type of the variable may be specified in dozens of places. If the type later changes, all the casts must be changed to match. The compiler may or may not detect if the hapless maintenance programmer fails to catch them all (or changes one too many). In a similar way, all matching casts to (short) need to be changed to (int) if the type of a variable changes from short to int. There is a movement afoot in invent a generic cast operator (cast) and a generic conversion operator (convert) that would require no maintenance when the type of variable changes. Make sure this heresy never makes it into the language specification. Vote no on RFE 114691 and on genericity which would eliminate the need for many casts.

Exploit Java's Redundancy

Java insists you specify the type of every variable twice. Java programmers are so used to this redundancy they won't notice if you make the two types slightly different, as in this example:
Bubblegum b=new Bubblegom();
Unfortunately the popularity of the ++ operator makes it harder to get away with pseudo-redundant code like this:
swimmer = swimner + 1;

Never Validate

Never check input data for any kind of correctness or discrepancies. It will demonstrate that you absolutely trust the company's equipment as well as that you are a perfect team player who trusts all project partners and system operators. Always return reasonable values even when data inputs are questionable or erroneous.

Be polite, Never Assert

Avoid the assert() mechanism, because it could turn a three-day debug fest into a ten minute one.

Avoid Encapsulation

In the interests of efficiency, avoid encapsulation. Callers of a method need all the external clues they can get to remind them how the method works inside.

Clone & Modify

In the name of efficiency, use cut/paste/clone/modify. This works much faster than using many small reusable modules. This is especially useful in shops that measure your progress by the number of lines of code you've written.

Use Static Arrays

If a module in a library needs an array to hold an image, just define a static array. Nobody will ever have an image bigger than 512 x 512, so a fixed-size array is OK. For best precision, make it an array of doubles. Bonus effect for hiding a 2 Meg static array which causes the program to exceed the memory of the client's machine and thrash like crazy even if they never use your routine.

Dummy Interfaces

Write an empty interface called something like "WrittenByMe", and make all of your classes implement it. Then, write wrapper classes for any of Java's built-in classes that you use. The idea is to make sure that every single object in your program implements this interface. Finally, write all methods so that both their arguments and return types are WrittenByMe. This makes it nearly impossible to figure out what some methods do, and introduces all sorts of entertaining casting requirements. For a further extension, have each team member have his/her own personal interface (e.g., WrittenByJoe); any class worked on by a programmer gets to implement his/her interface. You can then arbitrary refer to objects by any one of a large number of meaningless interfaces!

Giant Listeners

Never create separate Listeners for each Component. Always have one listener for every button in your project and simply use massive if...else statements to test for which button was pressed.

Too Much Of A Good Thing^TM

Go wild with encapsulation and oo. For example:
myPanel.add( getMyButton() );
private JButton getMyButton()
{
return myButton;
}
That one probably did not even seem funny. Don't worry. It will some day.

Friendly Friend

Use as often as possible the friend-declaration in C++. Combine this with handing the pointer of the creating class to a created class. Now you don't need to fritter away your time in thinking about interfaces. Additionally you should use the keywords private and protected to prove that your classes are well encapsulated.

Use Three Dimensional Arrays

Lots of them. Move data between the arrays in convoluted ways, say, filling the columns in arrayB with the rows from arrayA. Doing it with an offset of 1, for no apparent reason, is a nice touch. Makes the maintenance programmer nervous.

Mix and Match

Use both accessor methods and public variables. That way, you can change an object's variable without the overhead of calling the accessor, but still claim that the class is a "Java Bean". This has the additional advantage of frustrating the maintenence programmer who adds a logging function to try to figure out who is changing the value.

Wrap, wrap, wrap

Whenever you have to use methods in code you did not write, insulate your code from that other dirty code by at least one layer of wrapper. After all, the other author might some time in the future recklessly rename every method. Then where would you be? You could of course, if he did such a thing, insulate your code from the changes by writing a wrapper or you could let VAJ handle the global rename. However, this is the perfect excuse to preemptively cut him off at the pass with a wrapper layer of indirection, before he does anything idiotic. One of Java's main faults is that there is no way to solve many simple problems without dummy wrapper methods that do nothing but call another method of the same name, or a closely related name. This means it is possible to write wrappers four-levels deep that do absolutely nothing, and almost no one will notice. To maximise the obscuration, at each level, rename the methods, selecting random synonyms from a thesaurus. This gives the illusion something of note is happening. Further, the renaming helps ensure the lack of consistent project terminology. To ensure no one attempts to prune your levels back to a reasonable number, invoke some of your code bypassing the wrappers at each of the levels.

Wrap Wrap Wrap Some More

Make sure all API functions are wrapped at least 6-8 times, with function definitions in separate source files. Using #defines to make handy shortcuts to these functions also helps.

No Secrets!

Declare every method and variable public. After all, somebody, sometime might want to use it. Once a method has been declared public, it can't very well be retracted, now can it? This makes it very difficult to later change the way anything works under the covers. It also has the delightful side effect of obscuring what a class is for. If the boss asks if you are out of your mind, tell him you are following the classic principles of transparent interfaces.

The Kama Sutra

This technique has the added advantage of driving any users or documenters of the package to distraction as well as the maintenance programmers. Create a dozen overloaded variants of the same method that differ in only the most minute detail. I think it was Oscar Wilde who observed that positions 47 and 115 of the Kama Sutra were the same except in 115 the woman had her fingers crossed. Users of the package then have to carefully peruse the long list of methods to figure out just which variant to use. The technique also balloons the documentation and thus ensures it will more likely be out of date. If the boss asks why you are doing this, explain it is solely for the convenience of the users. Again for the full effect, clone any common logic and sit back and wait for it the copies to gradually get out of sync.

Permute and Baffle

Reverse the parameters on a method called drawRectangle(height, width) to drawRectangle(width, height) without making any change whatsoever to the name of the method. Then a few releases later, reverse it back again. The maintenance programmers can't tell by quickly looking at any call if it has been adjusted yet. Generalisations are left as an exercise for the reader.

Theme and Variations

Instead of using a parameter to a single method, create as many separate methods as you can. For example instead of setAlignment(int alignment) where alignment is an enumerated constant, for left, right, center, create three methods setLeftAlignment, setRightAlignment, and setCenterAlignment. Of course, for the full effect, you must clone the common logic to make it hard to keep in sync.

Static Is Good

Make as many of your variables as possible static. If you don't need more than one instance of the class in this program, no one else ever will either. Again, if other coders in the project complain, tell them about the execution speed improvement you're getting.

Cargill's Quandry

Take advantage of Cargill's quandary (I think this was his) "any design problem can be solved by adding an additional level of indirection, except for too many levels of indirection." Decompose OO programs until it becomes nearly impossible to find a method which actually updates program state. Better yet, arrange all such occurrences to be activated as callbacks from by traversing pointer forests which are known to contain every function pointer used within the entire system. Arrange for the forest traversals to be activated as side-effects from releasing reference counted objects previously created via deep copies which aren't really all that deep.

Packratting

Keep all of your unused and outdated methods and variables around in your code. After all - if you needed to use it once in 1976, who knows if you will want to use it again sometime? Sure the program's changed since then, but it might just as easily change back, you "don't want to have to reinvent the wheel" (supervisors love talk like that). If you have left the comments on those methods and variables untouched, and sufficiently cryptic, anyone maintaining the code will be too scared to touch them.

And That's Final

Make all of your leaf classes final. After all, you're done with the project - certainly no one else could possibly improve on your work by extending your classes. And it might even be a security flaw - after all, isn't java.lang.String final for just this reason? If other coders in your project complain, tel...