Productivity in programming of C++ programmers

[Siemel Naran]

Re: Productivity in programming of C++ programmers

"N4M" <dnguyenk@yahoo .com> wrote in message
[color=blue]
> May I ask how productivity of a(C++) programmer can be measured?
> If it is measured by number of code lines per day, what are the
> estimated productivity of a programmer at beginer, intermediate (Me),
> advance, master, guru,and sifu (B.Stroustrup, H.Sutter, S. Meyer)?
> Thanks for your guidance.[/color]

Also, there are companies that in the interview ask you how many lines of
code you've written. One even said they won't consider anyone who wrote
less than 5000 lines. Not sure what they're after, though there is some
sense to the question.

So how about:

int main() {
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
std::cout << "hello world!\n";
...
}

[Phlip]

Re: Productivity in programming of C++ programmers

Siemel Naran wrote:
[color=blue]
> Also, there are companies that in the interview ask you how many lines of
> code you've written. One even said they won't consider anyone who wrote
> less than 5000 lines. Not sure what they're after, though there is some
> sense to the question.[/color]

I know a guy who has a very nice Web appliance, written in Java, unaware of
his line count. Testing and refactoring were working. I started copying
Reggae files to his workstation, he asked why, I said I'm making room for
your program, he said it wasn't that big, and I showed him. Here's your
biggest folder, and it's all full of source.

All interview questions reveal something about the hiring company...
[color=blue]
> So how about:
>
> int main() {
> std::cout << "hello world!\n";
> std::cout << "hello world!\n";[/color]

You cheat! You didn't write them, you copied them!

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Phlip]

Re: Productivity in programming of C++ programmers

David wrote:
[color=blue]
> I work that way. If you have a clear idea what portion of the code
> should be abstracted you may do so. It might be best to keep the design
> simple in the generic portion so as to minimize the time you need to
> code up a single task that now has a few extra concepts embedded. I
> leave lots of comments (//@@@ in C++) that let me know where I've left
> incomplete concepts for further development. As for knowing when some
> concept may need to be generalized, that may be known in advance,
> become obvious sometime later, or never really be needed. We just need
> to insure that we don't over develop concepts and get away from our
> desired work.[/color]

There are those who think planning designs causes bugs, and lowers
maintainability .

So, how much time do you spend debugging? And how well have modules written
like this been re-used and maintained over time?

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[David]

Re: Productivity in programming of C++ programmers

Hi Phlip,

On Thu, 12 Aug 2004 09:38:03 UTC, "Phlip" <phlip_cpp@yaho o.com> wrote:
[color=blue]
> David wrote:
>[color=green]
> > I work that way. If you have a clear idea what portion of the code
> > should be abstracted you may do so. It might be best to keep the design
> > simple in the generic portion so as to minimize the time you need to
> > code up a single task that now has a few extra concepts embedded. I
> > leave lots of comments (//@@@ in C++) that let me know where I've left
> > incomplete concepts for further development. As for knowing when some
> > concept may need to be generalized, that may be known in advance,
> > become obvious sometime later, or never really be needed. We just need
> > to insure that we don't over develop concepts and get away from our
> > desired work.[/color]
>
> There are those who think planning designs causes bugs, and lowers
> maintainability .[/color]

I would disagree with that general statement. I am generally opposed
to teams or individuals that design way too much in advance, whithout
a clear idea of where the project is going to go.

If done well, a forethinking design can be a good plan for growth.
When done poorly, the implemented design may not actually match the
problem and have to be reworked or worked around later.

I think it all comes down to your (you, team, company) ability to
design up front. You may be good at working out much of the design
in advance or taking it in more reasonable steps and refactoring
along the way. Its best to know your abilities and limits and
work productively.
[color=blue]
> So, how much time do you spend debugging? And how well have modules written
> like this been re-used and maintained over time?[/color]

In the sense of debugging after the fact (as in post release) next to
none. Its been years since I've had a problem. Now, that doesn't mean
my code is absolutely perfect, or even all mine. I've inherited many
projects and written many of my own. Over time, the frailties of those
code bases have been improved to be more reliable.

I have adopted many ideas that go into developing an idea. Its well
thought out in advance, months if possible. Those designs don't usually
differ much from my initial ten minute impression of the project. It
does give me time to plan all the work and fill in the holes as to what
will be needed in terms of code, skills, and so on. I wil not write
any code that has not been tested by myself to its abilities. So, if
I write 100 lines today (I prefer the term concepts, FPs, or stories)
they must all be tested and approved. If they can fail, and most code
can, I absolutely must be able to debug the problem at a distance.
That is, the customer calls in to customer support with a vague description,
and I must be able to diagnose and fix the problem very quickly. I
generally do this by using extensive logs lying around. You must be
able to be able to trace back what has happened and where the failure
was. My first teachers insisted on writing code that worked within
three tries. In today's terms, that means when I start coding, I
have about three times for the entire [compile, run, validate, verify]
process to work. Most of my stuff is based on the usual C++ GUI
code on Windows these days. I also do a fair amount of embedded
work. It doesn't need to be this reliable, I just find it much better
to work this way. In a sense, I've been using most of what you'd
call agile, XP, and a few dozen models, for years.

As for reuse, I prefer to reuse as much as possible. A message
composer is likely to be used in several places -- an embedded project,
in a critical path (say a service), or in an application (GUI).
Look at my past posts and see what I've asked for help with. Its
mostly finding the proper way to accomplish a task which then becomes
(a class, template, or model) for doing that task well in the future.
If there was a problem later, I can point to all the code where the
mistake was made, what it might affect, and how to go about correcting
the problem.

I'd like to say more, but I have to get to work. I can't
summarize my 28 years of aquiring good techniques based on
the writings, teachings, and so on of other peoples work in
just a few lines of a post. We all need to understand there
are many ways to perform our daily tasks and seek to improve
them.

Take care,

David

[Siemel Naran]

Re: Productivity in programming of C++ programmers

"Phlip" <phlip_cpp@yaho o.com> wrote in message news:gSGSc.3032
[color=blue]
> All interview questions reveal something about the hiring company...[/color]

Such as?

[Phlip]

Re: Productivity in programming of C++ programmers

Siemel Naran wrote:
[color=blue]
> Phlip wrote:
>[color=green]
> > All interview questions reveal something about the hiring company...[/color]
>
> Such as?[/color]

They think A> a programmer should have a high KLOC rate, and B> a programmer
should be proud of it.

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Jerry Coffin]

Re: Productivity in programming of C++ programmers

Bob Hairgrove <invalid@bigfoo t.com> wrote in message news:<kdjih0h4l et99kv0sqsbbgn2 ct9jod6mbi@4ax. com>...

[ ... ]
[color=blue]
> What about "feature creep"?[/color]

It sucks. What else can be said? :-)
[color=blue]
> I would say that, ideally, "line creep" should grow logarithmically
> with "feature creep", not directly proportional (or even exponential).
>
> If this can be obtained, maximum efficiency has been reached.[/color]

Nah -- maximum efficiency is when you add a feature by removing code.
Of course, it indicates that the code was previously somewhat
inefficient, but truly optimal code is truly rare.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[lilburne]

Re: Productivity in programming of C++ programmers



Jerry Coffin wrote:[color=blue]
>
> Just for example, one of the oldest and best-known software metrics is
> McCabe Cyclometric Complexity. This is based on a count of the number
> of decision points in a module (e.g. if, for, while statements).
> Unfortunately, even with relatively average types of code, the
> correlation between its result and the maintainability of the code is
> close to zero, and seems to be negative about as often as positive.
> This is poor correlation at best, but if you add (for one example)
> even a trivial finite state machine, it can blow up entirely,
> basically doing its best to tell you that FSMs (in general) are evil
> and impossible to read.
>[/color]

I remember a paper about 10-12 years ago that examined a lot of the
weaknesses in these metrics. The problem with McCabe is that you if you
do a random permutation of the input source you'll get the same metric
result as you got for the original. The metric for a 6 deep nested loop
is the same as 6 loops one after the other.

What McCabe tells you is that big functions are bad.

However, you do get a number which you can use to beat people up with.
For example "This code is shit and it has a McCabe metric of 200".

The McCabe tools can be useful for pin pointing potential problem
points. For example you can get automated reports generated for code
changes that might need some independent review. I also find the
function graphing to be useful to see when cut&paste has been used.

[lilburne]

Re: Productivity in programming of C++ programmers



Siemel Naran wrote:[color=blue]
>
> In a similar manner, I may make functions inline before profiling. For
> example, std::complex::r eal() would be inline. Mostly because it's easier
> to write, uses fewer lines of code. But in any case, it seems the inline
> should make things faster.
>[/color]

One of my pet hates.

I make all developers remove inline functions from their code unless
they can demonstrate a measurable speed up. Even then they don't get to
stuff them in the header.

[Siemel Naran]

Re: Productivity in programming of C++ programmers

"lilburne" <lilburne@godzi lla.com> wrote in message
news:2o3l0eF6at nnU1@uni-berlin.de...[color=blue]
> Siemel Naran wrote:[/color]
[color=blue][color=green]
> > In a similar manner, I may make functions inline before profiling. For
> > example, std::complex::r eal() would be inline. Mostly because it's[/color][/color]
easier[color=blue][color=green]
> > to write, uses fewer lines of code. But in any case, it seems the[/color][/color]
inline[color=blue][color=green]
> > should make things faster.[/color]
>
> One of my pet hates.
>
> I make all developers remove inline functions from their code unless
> they can demonstrate a measurable speed up. Even then they don't get to
> stuff them in the header.[/color]

Even if it just returns a member variable by value?

[Phlip]

Re: Productivity in programming of C++ programmers

lilburne wrote:
[color=blue]
> Siemel Naran wrote:[/color]
[color=blue][color=green]
> > In a similar manner, I may make functions inline before profiling. For
> > example, std::complex::r eal() would be inline. Mostly because it's[/color][/color]
easier[color=blue][color=green]
> > to write, uses fewer lines of code. But in any case, it seems the[/color][/color]
inline[color=blue][color=green]
> > should make things faster.[/color][/color]
[color=blue]
> One of my pet hates.
>
> I make all developers remove inline functions from their code unless
> they can demonstrate a measurable speed up. Even then they don't get to
> stuff them in the header.[/color]

C++ has an annoying tradeoff between cognitive and physical efficiency.

If you inline all methods inside classes unless profiling reveals the need
to outline them, your code is more cognitively efficient.

If you put all classes in .cpp files without a reason to publish them, then
your header files don't get obese and cause cascading recompiles at change
time.

The rules that all classes go in header files deteriorates compiler
performance. Then rules to address the symptoms, such as putting all
implementations into .cpp files, deteriorates programmer performance

(You are lilburne, not James Kanze, so I ain't gonna do what you say! ;-)

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[lilburne]

Re: Productivity in programming of C++ programmers

Siemel Naran wrote:[color=blue][color=green]
>>
>>I make all developers remove inline functions from their code unless
>>they can demonstrate a measurable speed up. Even then they don't get to
>>stuff them in the header.[/color]
>
>
> Even if it just returns a member variable by value?
>[/color]

Yes! It keeps the rule simple

"Don't make functions inline unless you can show
a measurable speed up by doing so"

start adding more caveats and they'll think that maybe you
aren't serious.

Now you don't want to stick your inline definitions within
the class itself like

class A{
int m_i;
public:
A(int i) : m_i(i) {};
};

because you'll never be able to debug when A::A(int i) gets
called. So you'll write something like

class A{
int m_i;
public:
A(int i);
};

#include A.i

and within the A.i file you write

#ifndef OUTLINE
inline A::A(int i) : m_i(i) {}
#endif

but then you need a third file to create outline versions of
the file so that you can debug the damn things:


#ifdef DEBUG
#define inline
#undef OUTLINE

#include A.i

#endif

all of which is a burden on the build system and best
avoided, unless there is a performance advantage.

[lilburne]

Re: Productivity in programming of C++ programmers

Phlip wrote:[color=blue]
>
> If you inline all methods inside classes unless profiling reveals the need
> to outline them, your code is more cognitively efficient.[/color]


Nah! It just clutters up the thing making it impossible to
read. I want to see API not implementation.

[color=blue]
> If you put all classes in .cpp files without a reason to publish them, then
> your header files don't get obese and cause cascading recompiles at change
> time.
>[/color]

Don't you just hate it when that happens, and 20% of the
time the dependency is spurious anyway.

[Phlip]

Re: Productivity in programming of C++ programmers

lilburne wrote:
[color=blue]
> Phlip wrote:[/color]
[color=blue][color=green]
> > If you inline all methods inside classes unless profiling reveals the[/color][/color]
need[color=blue][color=green]
> > to outline them, your code is more cognitively efficient.[/color][/color]
[color=blue]
> Nah! It just clutters up the thing making it impossible to
> read. I want to see API not implementation.[/color]

And... it... makes... it... look... like...

====> JAVA <====

AAAAAUUGGGGHHHH ! Run screaming!

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Siemel Naran]

Re: Productivity in programming of C++ programmers

"lilburne" <lilburne@godzi lla.net> wrote in message
news:2o4qhhF6tj asU1@uni-berlin.de...[color=blue]
> Siemel Naran wrote:[/color]
[color=blue][color=green]
> > Even if it just returns a member variable by value?
> >[/color]
>
> Yes! It keeps the rule simple
>
> "Don't make functions inline unless you can show
> a measurable speed up by doing so"
>
> start adding more caveats and they'll think that maybe you
> aren't serious.
>
> Now you don't want to stick your inline definitions within
> the class itself like
>
> class A{
> int m_i;
> public:
> A(int i) : m_i(i) {};
> };
>
> because you'll never be able to debug when A::A(int i) gets
> called. So you'll write something like
>
> class A{
> int m_i;
> public:
> A(int i);
> };
>
> #include A.i
>
> and within the A.i file you write
>
> #ifndef OUTLINE
> inline A::A(int i) : m_i(i) {}
> #endif[/color]

All my compilers let you debug inline functions (Borland 6, MSVC 7, MSVC 6,
gdb g++).