As they say the software developer's best friend is the Ctrl+C - Ctrl+V...

I have never considered as a reusable code of using libraries though.
Interesting approach.

Tamas


On Sun, May 24, 2009 at 11:16 AM, Vitaliy <spam@maksimov.org> wrote:

> > Vitaliy wrote:
> >> My point is, you can be more productive if you
> >> can use code that has already been written,
>
> Olin said:
> > This is usually not true in my experience.  Most other code is crap, or
> > wouldn't fit into my system nicely without more work then to write it the
> > way I want from scratch.  Code re-use sounds nice in principle, but in
> > practise I find it way overrated.
>
> Isaac Marino Bavaresco responded with:
> > It appears that 99.9% of the programmers think this way (me included),
> > because of coding style or other subtle details. I try to get over such
> > prejudices so I can use others code.
> > There is a lot of bad code around, but there is a lot of good code also.
> > If you get a nice piece of code, use it, or at least use it as a base to
> > write your own.
> > I save much time this way.
>
> My experience with code reuse on embedded systems, falls into several
> categories:
>
>
> 1. Standard C libraries. Typically they're plug-and-play, because they were
> designed with reuse in mind by people who knew what they were doing. My
> only complaint here is that sometimes it's difficult to remember which
> function lives in which library ("is memcpy() in stdlib.h or string.h?"),
> which means that the libraries aren't as cohesive as they could have been.
>
>
> 2. Microchip C libraries. Possibly some of the ugliest library code ever
> written. Here's an excerpt from the 24F library docs, which shows the code
> necessary to perform a very common, simple operation -- configuring and
> opening the UART:
>
> =========
> /* Configure uart1 receive and transmit interrupt */
>   ConfigIntUART1(UART_RX_INT_EN & UART_RX_INT_PR6 &
>                  UART_TX_INT_DIS & UART_TX_INT_PR2);
> /* Configure UART1 module to transmit 8 bit data with one stopbit.
>   Also Enable loopback mode */
>   baudvalue = 5;
>   U1MODEvalue = UART_EN & UART_IDLE_CON &
>   UART_DIS_WAKE & UART_EN_LOOPBACK &
>   UART_EN_ABAUD & UART_NO_PAR_8BIT &
>   UART_1STOPBIT;
>   U1STAvalue = UART_INT_TX_BUF_EMPTY &
>   UART_IrDA_POL_INV_ZERO & UART_SYNC_BREAK_DISABLED &
>   UART_TX_ENABLE & UART_INT_RX_3_4_FUL &
>   UART_ADR_DETECT_DIS &
>   UART_RX_OVERRUN_CLEAR;
>   OpenUART1(U1MODEvalue, U1STAvalue, baudvalue);
> =========
>
> After the nausea subsides, the natural reaction is to say "forget this,
> I'll
> just configure the registers myself!"
>
> Another approach is to hide this ugliness behind adapter functions, so the
> code
> above could be replaced with:
>
>    Uart_Init();
>    Uart_SetBaudRate(9600);
>    Uart_Open();
>
> Other ugly uChip functions can be dealt with, in the same way. The
> advantage
> of this approach is that you can get a proof of concept, or even a fully
> functional product, very quickly. What happens in our situation, is that
> the
> Microchip code inevitably gets replaced, piece-by-piece, with our own code.
> This improves readability, and as a side effect, increases performance and
> reduces footprint.
>
>
> 3. Other people's (non-library) code. Depending on the quality of the code,
> refactoring may get you where you want to be faster than if you had to
> write
> the code from scratch.
>
>
> 4. Our "in-house" code. We practice the "tight cohesion, loose coupling"
> rule, which allows code reuse with a minimal amount of effort. In fact, I
> was surprised when it turned out that modules written for one project,
> could be used in another project without _any_ modifications.
>
> Note that the modules in question were not specifically designed for reuse.
> We did not put any provisions "for future expansion", or made compromises
> to
> make the modules "fit".
>
>
> Code reuse is the king in the PC apps/Windows world. You get tons of
> functionality without writing a single line of code: Windows takes care of
> handling mouse clicks, drawing windows, buttons, text boxes, etc. There
> are libraries of custom components to do virtually everything. They can be
> dropped into your project, and require only a small amount of "glue" code.
> There, only masochists and lunatics would insist on writing the code from
> scratch.
>
> The situation is different in the embedded world, but nonetheless I think
> the problem has more to do with the mindset of embedded programmers, than
> with the special attributes of embedded programming that make it different
> from other types of software development.
>
> Best regards,
>
> Vitaliy
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
http://www.mcuhobby.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist