Eclecticism

1
Eclecticism

• Pronunciation e-'klek-tik
• 1 selecting what appears to be best in various
  doctrines, methods, or styles
• 2 composed of elements drawn from various
  sources

2
Dogma

• Pronunciation 'dog-m, 'däg-1 something held
  as an established opinion especially a
  definite authoritative tenet
• 2 a code of such tenets ltpedagogical dogmagt
• 3 a point of view or tenet put forth as
  authoritative without adequate grounds

3
get a sense of perspective

• Go-tos, pointers, and issues of clarity
• Go-tos are not to be avoided at all costs. It
  is, instead, serpentine code that needs to be
  avoided. Simplicity and clarity should override
  most other design decisions. A go-to, in
  particular, is a powerful tool when used as a
  direct, no-nonsense jump under well-stated
  conditions, and can very closely follow
  problem-space behavior if used with some planning
  and forethought (Ada, a language designed from
  scratch by smart French people, contains a goto
  keyword). On the other hand, the indirection of a
  pointer tends to be a computer-space construct,
  that is often confusing and - if honesty should
  prevail - unnecessary (Java, the latest geek
  programming language, does not allow the use of
  pointers).
• ... Eastman Kodaks coding standards

4
Religious Wars

• Coding Standards
• Bracket Placement
• Variable Names / Naming Conventions
• Indentation
• OO vs. non-OO (you can, but should you?)
• Differences between what you can do and what you
  should do (multi-platform? configurability?)
• Design Patterns vs. Design
• Documentation Standards

5
A Real Coding Standards Defense
The Emotional Topic of Coding Standards Please be
patient with these coding standards until they
become natural... it is only then that an honest
opinion as to correctness or utility can be
formed. They need not impede the feeling of
craftsmanship that comes with writing software.
Consider the common good. Embrace the decisions
of the group. A Limited Lifetime Warranty If
these standards - when used as directed - fail to
perform as expected, they can be edited and
adapted to changing environments, applications,
business emphasis, and an ever-evolving industry.
The spirit of this document, not its rules,
should dictate the place of standards and
consistency within and across projects. I Never
Learned This in School Is This a Joke? You have
to use some style, why not be consistent across
the project? Individual styles are not best just
because theyre individual. Individual styles are
learned in a non-business environment
(school?). Any style becomes natural after
100,000 lines. Syntax-based editors can be
configured to do the mundane tasks
6
More

• Other clarity-based suggestions
• Use case statements instead of nested ifs, use
  arrays instead of linked lists, optimize through
  solid design rather than bit-tuning, get a faster
  CPU instead of writing assembler, pay for the
  extra memory, buy code if its available.
• Strive to develop clear code
• Engineers should strive to develop code that is
  both clear, and efficient in its use of CPU time,
  memory, and other resources. However, when
  efficiency and clarity conflict, then clarity
  should take strong precedence over resource
  stinginess, unless it is proven that using the
  clear but less efficient method impairs the
  program critically. Micro-optimizations to small
  areas of code are especially to be avoided if
  they impair clarity in any way, since it is
  generally only the programs overall algorithms
  that affect resource utilization significantly.

7
OO, Java, Design Patterns, XP

• Object Oriented Java supplemented by Design
  Patterns in an Extreme Programming methodology is
  the quickest way to develop high quality code, on
  a large scale, in a team and business
  environment. It represents the greatest advances
  in computer language use since high level
  languages were invented.

8
however
9
Applications where you have to adapt

• Legacy Systems
• Digital Signal Processing
• Mobile Devices phones, mp3, etc
• Vendor-native (Windows Mobile, PalmOS, VxWorks)
• some Games
• Industrial Control PLCs
• Embedded Devices auto computers, etc.

10
The Dumbing Down of Programming

• An immense calm settled over the room. We were
  reminded that software engineering was not about
  right and wrong but only better and worse,
  solutions that solved some problems while
  ignoring or exacerbating others. That the machine
  that all the world seems to want to see as
  possessing some supreme power and intelligence
  was indeed intelligent, but only as we humans
  are full of hedge and error, brilliance and
  backtrack and compromise. That we, each of us,
  could participate in this collaborative endeavor
  of creating the machine, to the extent we could,
  and to the extent we wished.
• Ellen Ullman

11

• Now begins a process of frustration. The
  programmer goes back to the analysts with
  questions, the analysts to the users, the users
  to their managers, the managers back to the
  analysts, the analysts to the programmers. It
  turns out that some things are just not
  understood. No one knows the answers to some
  questions. Or worse, there are too many answers.
  A long list of exceptional situations is
  revealed, things that occur very rarely but that
  occur all the same. Should these be programmed?
  Yes, of course. How else will the system do the
  work human beings need to accomplish? Details and
  exceptions accumulate. Soon the beautiful crystal
  must be recut. This lovely edge and that are
  lost. What began in a state of grace soon reveals
  itself to be a jumble. The human mind, as it
  turns out, is messy.

12

• Gone is the calm, mathematical world. The whole
  endeavor has become a struggle against disorder.
  A battle of wills. A testing of endurance.
  Requirements muddle up changes are needed
  immediately. Meanwhile, no one has changed the
  system deadline. The programmer, who needs
  clarity, who must talk all day to a machine that
  demands declarations, hunkers down into a
  low-grade annoyance. It is here that the
  stereotype of the programmer, sitting in a dim
  room, growling from behind Coke cans, has its
  origins. The disorder of the desk, the floor the
  yellow post-it notes everywhere the white boards
  covered with scrawl all this is the outward
  manifestation of the messiness of human thought.
  The messiness cannot go into the program it
  piles up around the programmer.

13
(No Transcript)
14

• Soon the programmer has no choice but to retreat
  into some private interior space, closer to the
  machine, where things can be accomplished. The
  machine begins to seem friendlier than the
  analysts, the users, the managers. The real-world
  reflection of the program -- who cares anymore?
  Guide an X-ray machine or target a missile print
  a budget or a dossier run a city subway or a
  disk-drive read/write arm it all begins to blur.
  The system has crossed the membrane -- the great
  filter of logic, instruction by instruction --
  where it has been cleansed of its linkages to
  actual human life.
• Ellen Ullman