[OT] Development workflow

[OT] Development workflow

[Chris Rose]

Can any of the linux users on here who still develop on the console 
(preferably w/ vi, since i'm not really an emacs fan {/me ducks}) weigh 
in with tips on how their workflow actually runs?  How do you organize
things, what programs do you need, etc...  Note that i'm thinking 
specifically of c++ here, and i'll probably be using the gcc compiler 
toolkit.  At this stage of my development, while i can read individual 
snippets of c++ code and understand them, i'm still not very good at 
figuring out how they fit into the larger context of a program.  (this 
last bit of self-description is by way of showing how little i know so 
you'll use small words and write slowly ;)

I'm totally unfamiliar w/ development like that, having only ever worked 
in IDEs, and it happens that i'm gonna have to learn how to do it next 
year, so i want to get a jump on it.  Incl. debugging.

Thanks in advance.

-- 
Chris
http://offline.pointclark.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: [OT] Development workflow

[John Kelly]

On Monday 30 June 2003 8:20 am, Chris Rose wrote:
> Can any of the linux users on here who still develop on the console
> (preferably w/ vi, since i'm not really an emacs fan {/me ducks}) weigh
> in with tips on how their workflow actually runs?  How do you organize
> things, what programs do you need, etc...  Note that i'm thinking
> specifically of c++ here, and i'll probably be using the gcc compiler
> toolkit.  At this stage of my development, while i can read individual
> snippets of c++ code and understand them, i'm still not very good at
> figuring out how they fit into the larger context of a program.  (this
> last bit of self-description is by way of showing how little i know so
> you'll use small words and write slowly ;)
>
> I'm totally unfamiliar w/ development like that, having only ever worked
> in IDEs, and it happens that i'm gonna have to learn how to do it next
> year, so i want to get a jump on it.  Incl. debugging.
>
> Thanks in advance.
Hi,
I am not sure if I should answer this or not as:
1) My favourite statement was 'I am not a developer'  when I was working in 
IT  and 
2) I only 'don't develop' in perl C and bash.
But  as my last employer is still running many things I wrote and/or modified 
on my 486 laptop - to slow running a window manager, here goes:

The only things you really need are an editor and a compiler ie vi and gcc.

Make (man make) is useful for larger projects.
gdb (the GNU debugger) is useful but I normally just compiled the stuff and 
either got it to print or log lots of debugging or I used strace (man strace).

Getting to know vi very well also helps. I used vim - an improved vi which is 
used as vi on many systems and there are many tricks which help. 
The syntax options that come with vim can make writing code easier. See the 
vim documentation under /usr/share or /usr/local/share.
  
If you need to keep track of what you are doing then you need a versioning 
system. I used to use RCS (man -k rcs) as it was used at work. But cvs (man 
cvs) is probably better and more common 
The next thing I would look at is ctags ( man ctags), a program which helps 
to find the source file containing a specific function.

Other programs I used were:
gprof	Tells how long a program spends in each function
time	How long a program takes to run 

Other useful, but more advanced programs which I havn't used  but I  took 
from the Linux in a  Nutshell book are:
ar 	Create amd update library files
as 	Generate object files  
bison 	Generate parsing tables
ld	Link editor
flex	Lexical analyzer
m4	Macro processor
yacc	Generate parsing tables. 

One of the developers at work thought electric fence (checks memory 
allocation) was the most useful tool ever but I never used it.

As for workflow, I never wrote anything big or complex so I may not be the 
best person to advise. 
If I were modifying something, I would download the original source code to a 
new directory. Try to figure out how it worked and then go through a cycle of 
edit, compile and test. until I was happy with what I got. 

When writing something from scratch, I would start with skeleton code 
complete with dummy functions. I would go through my edit, complie and test 
routine and flesh it out as I went. 

Not very scientific but it worked for me. 

Where I worked nearly everything was custom written or heavily modified. Some 
people's code was logically laid out with useful comments and was very easy 
to read and modify if necessary. The real 'geniuses' wrote code which worked 
but was totally unintellible. I spoke to the chief developer there recently 
and he has the task of fixing some perl code, 35,000 lines long written by a 
guy, who didn't' know about comments, scoping variables or modules. 
Not nice.  

My advice would be:-
Comment your code, lay it out logically and don't be too clever.

Hope all this helps.

regards,

John Kelly
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: [OT] Development workflow

[jude dashiell]

Also, remember structured programming is your friend!  Many small files
preferably with no more than one task in them each with commenting can be
used to build large projects.  The advantages of doing this are a few.
First, you may be able to write a wrapper program that you can then use to
test your smaller files with independently of the whole system.  Second,
when something blows up you'll know which small program broke and won't
have to go looking through 35,000 lines of code to find that error, it'll
be in a file with no more than 50 active lines of code.  Find errors
faster you can fix them faster too.  Last and probably least important is
that once ou write the small programs provided you write them generally
enough you'll be able to steal from them in the future and make future
projects come up that much faster.  If you continue to add to your
library, there's a higher and higher likelyhood what's already in it gets
used and used again during your career.  Use a hierarchy input/output
chart to document relationships of the small files one to the other.  I
know, people who hate Cobol laugh at those things but if you take the time
to write out your hipo chart first you'll have first descriptions for
everything in your system you can copy into each small file as comment
headers.  If you break down and put a uses: and returns: line inside each
of the boxes on the hipo chart you'll almost have interface specifications
also written out.


-- Registered as user #315636 with the Linux Counter,
http://counter.li.org/!
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: [OT] Development workflow

[geoff bagley]

I have found the two "off topic" posts on Development workflow very
useful.  I am trying to make the change from Turbo Pacal 7.0 to Free
Pascal under GNU/Linux,  and miss the IDE.

Please what is a "hipo" chart ?

Best regards.
-- 
geoff bagley
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

[OT] Development workflow.

[geoff bagley]

Since my last post I have managed to decode the acronym "hipo".
I am familiar with the idea, but have not heard it called hat before!
Best regards.
-- 
Geoff Bagley
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs