ACCU :: Assumptions https://members.accu.org/index.php/articles/862 Professionalism in Programming en-us Administrator hourly 1 http://backend.userland.com/rss
CVu Journal Vol 11, #3 - Apr 1999
Browse in : All > Journals > CVu > 113

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: Assumptions

Author: 

Date: 03 April 1999 13:15:30 +01:00 or Sat, 03 April 1999 13:15:30 +01:00

Summary: 

Body: 

I was talking with someone at Apple who said he had once been asked to write an article on writing programs for the disabled and how this fits in with good programming in general, and he failed to see the connection. The connection is an example of a very fundamental thing: the avoidance of unnecessary assumptions.

When you program, you have to make assumptions, as the extreme in avoiding assumptions is letting the user write the program (something that this user too often has to resort to). Unless you want to write an omnipotent program, you have to assume that your program only needs to fulfil its specification. Whether that specification is formally documented or exists only in your mind, and whether or not you later amend it, is beside the point. The assumption of what your program is required to do is a good thing, as it allows you to know where you're going and start designing it.

Some assumptions, though, are not so good. When writing code, you can assume things nearly all the time that are nothing to do with your specification, and thus limit your program in ways that you did not realise. Or they could be in accordance with your specification, but your specification may not live up to your intentions as much as you think it does. These assumptions tend to restrict the portability of your program in ways you do not expect, and the ability to spot assumptions is a very valuable talent. "Portability" can have a very wide meaning. Here are some examples of assumptions that restrict portability:

  • Compiler portability: "I think all ints are 16 bits wide." This can give you problems on many compilers, and if you must assume it then perhaps it would be good to include a preprocessor sizeof() check so at least the person trying to compile your code has some clue as to what's wrong.

  • Scalability: "I think this program will never deal with files so big that you can't use a long as a pointer." On many architectures this will not scale beyond 2Gb; on some it will be less depending on the size of a long. Assuming that you can fit a certain amount of information in memory can also be flawed when dealing with huge amounts of data (many old DOS disk manager programs that try to log the whole drive into memory have problems with modern PC hard disks, let alone with corporate servers).

  • API portability: "I like drawing graphics with line(x,y)." This is a vendor-specific runtime library that will probably not work with other vendors or other operating systems. Encapsulation can help.

  • Hardware portability: "I think you can get 80 columns and 640 pixels on the screen." You may need to bear in mind other possibilities unless your program has a very limited internal domain.

  • Configuration portability: "I think all my users have small black fonts on a white background." If they have large yellow fonts on a black background then some of your layout and colour assumptions may fail and some parts of your program may be inaccessible.

  • Skill portability: "I think all my users have a PhD in Computer Science and no objections to reading long manuals." How expert or otherwise they have to be is something you have to decide.

  • Application domain portability: "I think this menu will never have so many items as to not fit on one screen." (Just try enlarging the fonts.)

  • User interface portability: "I think all my users like to point and click and like the Microsoft look-and-feel." Simply porting your program across different operating systems does not make it intuitive in each, nor does it make it universally accessible.

  • Language portability: "I think the length of my messages will never change." This will not internationalise, but almost as bad is setting an arbitrary limit on how much they can change.

  • Language culture portability: "I think all users start reading at the top left." If you want to internationalise your program then you will find that this assumption can break down.

And finally:

  • "I think the century never changes."

Notes: 

More fields may be available via dynamicdata ..