Subject: RE: [hackers-il] How to define "modular" code? [rather long]

From: Omer Musaev <[email-masked]>
Date: Sun, 21 Apr 2002 18:04:22 +0200

> -----Original Message-----
> From: Oleg Goldshmidt [mailto:[email-masked]]
> Sent: Sunday, April 21, 2002 2:05 PM
> To: [email-masked]
> Subject: Re: [hackers-il] How to define "modular" code? [rather long]
> 
> 
> Omer Musaev <[email-masked]> writes:
> 
> > The reason for a danger is that while code comes to solve a 
> > problem, modularity is a property, and not a goal. 
> 
> The implied goal is maintainability, I guess, and modularity is a way
> towards that goal. Performance issues (that was the "danger" of too
> much modularity alluded to by Omer earlier) are typically best
> addressed by identifying which "modules" (e.g. functions) are the
> bottlenecks, and optimizing these parts. Modularity helps here.
> Sometimes it is the function calls themselves (or other over-modular
> designs, such as those that plague C++/OOP programs all too often, as
> mentioned) are the problem. In these cases, they can more often than
> not be inlined to avoid call overhead without sacrificing modularity.
> 
> > > > > 5. Trying to keep functions non-monolithic and to split them
> > > > > into several logical routines.
> > > >
> > > > This is dangerous statement too. One can find himself 
> in "too many
> > > > layers of abstraction" hell quite easy.
> 
> The guiding principle is usually that a function should do 
> one thing well.
> 
> > > > > What else can you think of?
> 
> An issue that is often overlooked is dependencies. Code-level
> dependencies, compile-time dependencies, link-time dependencies, etc.
> In practical terms, this means thinking of physical organization of
> your program, dividing it into files, thinking what should go into
> source files and what into headers, hiding implementations, using
> forward declarations rather than including headers where sufficient,
> using techniques such as opaque pointers etc, etc.
> 
> Note that this is quite separate from abstracting actions into
> functions, which was the bulk of the discussion in this thread. 

I disagree. Code level dependencies are dependent on inner code 
structure.

> 
> -- 
> Oleg Goldshmidt | [email-masked] 
> [Lisp] is the only computer language that is beautiful. 
>                       - Neal Stephenson 
-- 
Omer Mussaev
Software Developer
Mercury Interactive / Topaz Prism R&D
Application Team

---

From: Oleg Goldshmidt <[email-masked]>
Date: 21 Apr 2002 18:17:55 +0300

Omer Musaev <[email-masked]> writes:

> Code level dependencies are dependent on inner code structure.

Sorry, Omer, I did not understand this sentence. Can you rephrase?