Re: Economy of Expression
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- Date: Tue, 25 Mar 2008 04:36:23 +1000
"Leslie Sanford" <jabberdabber@xxxxxxxxxxxxxxxxx> wrote in message news:47e74db4$0$6491$4c368faf@xxxxxxxxxxxxxxxxx
I'm wondering what are some approaches, ideas, conventions, etc,. that you
find helps you to get the job done while also helping you to write less
code. My own thought is that if you find yourself writing several
applications that belong to the same domain, you can optimize your
programming approach to fit the domain; hopefully, this leads to a reuseable
toolset that can help automate repeated tasks. Basically, I'm interested in what helps you get more done while writing less code.
split projects into pieces which interact only by the use of well-defined APIs.
this way, pieces can be reused in different contexts (they don't care what is on the other side), or replaced, without breaking the project or requiring large amounts of editing...
IMO, the APIs used should in general be as minimalistic and opaque as is reasonable, and the behavior of each piece is hopefully as simple and well defined as is reasonable.
for example, in many cases, it may well be most sensible to base the interface around abstract function calls, avoid any complex types (aka: structs or objects), instead making use of void pointers or integer handles (the later is prefferable if opaqueness is the goal).
at the same time, pieces should be as general-purpose as is reasonable as well. note: this does NOT mean making the piece overly complicated, or trying to engineer in every conceivable use case, which is IMO counter to what I am describing here (if one feels this is necessary, it may mean that the piece is too big and complicated anyways, and it may be better to subdivide the problem).
generality should instead involve limiting each piece to a well-defined task, and if possible avoiding arbitrary limits, design assumptions, or usage assumptions.
for example, if some abitrary internal property exists which changes the external behavior of the API, it should be either made external (a "settable option"), or be made an explicit part of the API's design.
....
we can then form a "toolbox" which may well include alternative versions of many of the same pieces, which may have the same external API (or, have very similar APIs, differing only in "prefix" or some other means), but may implement different behaviors or be implemented in different ways.
also, making APIs have as many general consistencies between each other as is reasonable is also a worthwhile goal.
more subtly, I think:
an API should also assume the "least common denominator", which may well imply using C, as opposed to C++, constructions for implementing the external API (as such, C++, if any, is confined to the internal machinery).
any structs or complex types should be avoided if possible (especially, if the user of the API is expected to directly interact with members). rather, it is preferable in this case to use abstract pointers and accessor functions.
callbacks and similar should be avoided if possible, along with any parts which implement blatently "non-atomic" behavior (such as, for example, needlessly demanding to hijack the main-loop, and expecting that the behavior that would normally be done in the main loop be handled in some or another callback-based interface). likewise, each function call should complete as quickly as possible, and any complex process should be broken into incremental/iterative steps.
if the above should be unreasonable, then it may make sense to use threading instead, or, inversely, threads are an exception because a thread need not be bound by the above rule. however, IMO, threading should only be used if necessary, and if used to be careful to limit the scope of its external effects (because we use threads in one place, we should not try to demand or force the entire rest of the app to be "thread safe" in response, albeit, if possible, an API should not assume that it is only being used by a single thread as well...).
....
of course, another policy of mine is "do whatever makes most sense".
pretty much any technique can be overused or abused.
.
- References:
- Economy of Expression
- From: Leslie Sanford
- Economy of Expression
- Prev by Date: Re: Search for an algorithm to deal cards with preset conditions
- Next by Date: Re: misc: Genetic Algorithms
- Previous by thread: Re: Economy of Expression
- Index(es):
Relevant Pages
|
