Re: Learning Code...Fast

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Quoted text here. Click to load it

Given an opportunity? Surely there are better things to do with your
life than slave over 100,000 lines of obscure code. Experienced
programmers either find interesting work or switch careers. Leave this
one for someone who has a financial stake in it, or for some brain-dead
  drone. Move onto something real.

--
Joe Legris


Re: Learning Code...Fast

Quoted text here. Click to load it

Why do you think this would not be interesting work? (leaving aside
the fact that the OP clearly stated that he does have a financial
stake in it.)

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning Code...Fast

Quoted text here. Click to load it

What gives you the idea we're all using Java?

Quoted text here. Click to load it

Furthermore, experienced programmers work where they
work for any number of reasons besides interesting
work.  Like benefits, working hours, money, nearby
skiing, cute coworkers and freedom from PHB's





Re: Learning Code...Fast
Quoted text here. Click to load it

   I just meant that those who do use Java might be using Zinc
instead.  But I'll save it for alt.history.what-if.

Re: Learning Code...Fast

Quoted text here. Click to load it

I saw Zinc library in early '90.  It was a rather impressive library of
primitives for creating user interfaces under DOS (C compiler was not
included).  How could that library be possibly used as a programming
language eludes me.

  Vadim

Re: Learning Code...Fast
Quoted text here. Click to load it

By financial stake I meant a profit/loss sharing potential. It's a great
way to make an onerous task look interesting.

Let's see now - 100,000 lines of old code, no documents, unrealistic
schedule. The silver lining - the opportunity to discover some subtle
bugs, which then become your problem. Which part of it excites you?

--
Joe Legris




Re: Learning Code...Fast
Quoted text here. Click to load it

Before touching one line of code, ensure you have the complete
tool chain to recreate the original, and to check that the result
is bit for bit identical.  Only after that can you afford to
revise the source and tool chain.

Then do cosmetic revisions on the source.  The thing that stands
out is the 'magic numbers'.  There is no reason for these, they
should be properly defined with meaningful names.  Such things as
consistent indentation and naming conventions can be inserted
here.  These revisions can be checked for identical binary
outputs.

If it doesn't exist, build a regression tester that can be easily
and automatically run.

Now you are ready to make real progress rapidly.  The up front
work will pay off, and you will find yourself able to make bolder
and bolder revisions as your understanding increases.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning Code...Fast

Quoted text here. Click to load it

Unless *you* get to decide what the word "possible" in that sentence
is supposed to actually mean, accepting that job would appear
suicidal, to me.

Quoted text here. Click to load it

"so there" implies the latter is a direct consequence of the former.
Mildly speaking, that's not exactly correct.  Just because it's an
embedded system doesn't mean the code must be crap.

Quoted text here. Click to load it

There are tools designed to help with that.  Automatic source code
analyzers that let you visually inspect the structure of the project.
RedHat Source Navigator would be one such tool worth trying, as long
as the actual source code is still parseable as C++.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Learning Code...Fast
Quoted text here. Click to load it

   I didn't mean that one implies the other.  I happen to have seen the code!
;-)

Re: Learning Code...Fast

Quoted text here. Click to load it

As others have pointed out, timescale may be the biggest problem for you.
These sort of things take as long as they are going to take. Offer no hard
promises of when the end date might be as it will all depend on the quality
of what you are inheriting (which, if documentation is lacking may be
dubious).
 
Quoted text here. Click to load it

There is no doubt but the first thing you will start doing is assembling
whatever your detective work can find by way of real documentation. This
means you finding the hardware data sheets, schematics, user manuals, any
design notes that may still be around etc. You should also find the
original compiler toolchain and recomp[ile the sources you find to ensure
they are complete. If you can compile the whole lot then compare with the
binary of a working unit (which I trust you will also have access to).

One other poster mentioned establishing a "war room" where you can hang the
printed listings of the code and mark it up as you find out things. If the
originalk author of this code has used a lot of magic numbers then put them
in either a named constant of clearly identify them with a named definition
of what they represent.

Don't forget, for your own sanity and the benefit of your paymasters, to
establish a review process by which you can be assured that your efforts
are progressing in the right diorection and they can see how the project
progresses. This way they will usually wear longer timescales if they see
progress being made but no way of helping to speed ity up.

Good luck if you accept the challenge.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning Code...Fast

Quoted text here. Click to load it

Absolutely, positively, and beyond a shadow of a doubt, the most
valuable tool I have used in these types of situations is "Understand
for C/C++" by Scientific Toolworks, Inc.

http://www.scitools.com/ucpp.html

I was introduced to it a few months ago on a 500K-line C program as a
contractor/consultant and found it *so invaluable* that I (how's that
electric shaver commercial go?) bought the product for my own
toolchest for those other clients that dump their code on me and ask
"how long will it take you to ________?".  Now I have a tool that give
me much more confidence in my Rough Order of Magnitude estimates for
performing modifications without breaking something else.

[I'm only a happy customer, nothing more.]

--
Dan Henry

Re: Learning Code...Fast

Quoted text here. Click to load it

I have used this tool as well, and can also recommend it. It is also
great for generating piles of documentation to keep certain types of
QA people happy. (Here in South Africa there is a tendancy to use
people who are useless at anything else for QA)
It of course can also be used to generate very usefull documentation
as well - hyperlinked to the actual source etc.

Regards
   Anton Erasmus


Site Timeline