Dear,
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.
NguyenMai
P/S: Similar post has been sent to comp.lang.c++.moderated (probably
takes longer time)
51  3464 
N4M wrote: May I ask how productivity of a(C++) programmer can be measured?
Do you want to rate individuals, or improve user productivity early and
often?
If the former, either run tests, or ask team members to vote on who, besides
themselves, helps the team the most.
If it is measured by number of code lines per day,
A line of code is _spent_, not gained.
To measure a team's productivity, every Monday select a few features of
highest business value. Spend the week implementing them, while writing unit
tests. Don't allow any code that does not support the current and new
features to remain in the codebase. Do not count lines, or reward based on
any ramp in line count. It should curve over (y^2 = x), not up.
On Friday, count the number of features implemented, burn a new version of
the program onto a CD, and pretend to deliver it.
Because this code is bug-free, and contains high-priority features, your
business managers have the option to deploy it to users. Whether they do or
not, the version should demonstrate the ability to boost user productivity.
The team's "velocity" is their number of features per week. Improve this
number by programming in small groups, not alone in individual offices, by
continuously integrating, and by passing all the tests between the fewest
possible edits, say 10 at the most.
what are the
estimated productivity of a programmer at beginer, intermediate (Me),
advance, master, guru,and sifu (B.Stroustrup, H.Sutter, S. Meyer)?
Tests have shown an order of magnitude improvement between intermediate and
guru level. Credit those authors with the experience to rarely get stuck,
but Bjarne shouldn't be revered if he didn't invent a language that others
could benefit from.
The best way to keep a team fast is to allow its gurus' influences to spread
rapidly. Keeping them alone and watching them shred is irrelevant to team
progress. And some folks are faster in some domains than others.
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
N4M wrote: Dear,
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)?
Lines of code is the worst metric to measure a programmers productivity.
It stimulates wrong behavior; you don't want programmers to maximize the
number of lines of code to accomplish a certain task.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Peter van Merkerk wrote: Lines of code is the worst metric to measure a programmers productivity.
It stimulates wrong behavior; you don't want programmers to maximize the
number of lines of code to accomplish a certain task.
One Peter Merel put it like this; "If you reward by lines of code,
programmers will automate code generation..."
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
N4M <dn******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om... Dear,
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.
I don't like wading around in philosophical swamps, but anyway ....
Note that the desired end result of programming is performing some function
thought to be useful, not lines of code. The better programmers may produce
less lines of code for the same end result. And the smallest program of all
may be the "worst" since it may be unmaintainable by ordinary mortals. And
on and on ...
So you have chosen a bad metric. And furthermore, some things can't be
measured, which does not diminish the *desire* to measure. I am fascinated
by what makes a woman beautiful, unfortunately I think I will go to the
grave no smarter on that issue than I am right now.
I can think of two ways to quantify, more or less, this issue. The opinion
of peers, or some kind of contest. Example:
Write an equivalent to Pretty Good Privacy. But some of the entrants will
have more prior knowledge than others, so several contests would ne needed.
> May I ask how productivity of a(C++) programmer can be measured?
Assume a time it might take for a certain task, then set a deadline at
half of that time. You will have to give time to finish the problem
(that's the other half of the esimated time).
Then pay your programmer for the time worked, or pay per project (and
you will get buggy crap)
Honestly, I don't think there's any way of measuring our work. You can
only trust or don't. And if you think someeone's too slow (in
comparison to others in your office) ask him/her about it.
-Gernot
N4M wrote: Dear,
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.
NguyenMai
P/S: Similar post has been sent to comp.lang.c++.moderated (probably
takes longer time)
Productivity must be measured along with other attributes.
I could crank out lousy code all day and be productive.
I could spend a day optimizing the code for speed or space when
optimization is not necessary.
I could spend a day reviewing other people's code. Yet I have
no quantitative or tanglible data for a metric. I know I've
helped in the overall productivity, but alas, it isn't measured
until the end.
I could spend my time writing quality code, yet not be very
"productive". I can spend my time writing robust code without
generating any data for the metrics.
Somethings in programming are more important than being
measurably productive.
--
Thomas Matthews
Software Rebel.
C++ newsgroup welcome message: http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq: http://www.comeaucomputing.com/learn/faq/
Other sites: http://www.josuttis.com -- C++ STL Library book
"Thomas Matthews" <Th****************************@sbcglobal.net> wrote in
message news:kG***************@newssvr16.news.prodigy.com. .. N4M wrote: Dear,
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.
NguyenMai
<<snip>> Somethings in programming are more important than being
measurably productive.
Yes. At IBM, many years ago, there was an attempt to measure programming.
They counted lines of code, percentage of comments, hours spent on
compilation, overtime put in, etc. Nothing made any sense. [When they
measured comments, claiming a good program would have 75%, there were
statements like
"LR reg7,reg9 load register 9 into register 7"]
The result? No answer. However, our team had exactly one bug reported in the
first year our code was release in the wild. Some groups had hundreds and
hundreds. Who was more productive? [I might add we delivered one week early,
which was the only time it ever happened!]
End result: the guys that were on good personal terms with their managers
got awards and raises. I think final salary is the measurement you are
looking for.
--
Gary
Thomas Matthews wrote:
Productivity must be measured along with other attributes.
I could crank out lousy code all day and be productive.
I could spend a day optimizing the code for speed or space when
optimization is not necessary.
I could spend a day reviewing other people's code. Yet I have
no quantitative or tanglible data for a metric. I know I've
helped in the overall productivity, but alas, it isn't measured
until the end.
I could spend my time writing quality code, yet not be very
"productive". I can spend my time writing robust code without
generating any data for the metrics.
Somethings in programming are more important than being
measurably productive.
I've discovered that more often than not, my third attempt at the same
problem results in far less code than the first. IOW, the better my code
gets, the less of it there is.
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
N4M wrote:
May I ask how productivity of a(C++) programmer can be measured?
If it is measured by number of code lines per day,
By that measure, my productivity is often negative. I consider those to
be very good days.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
Pete Becker wrote: N4M wrote:
May I ask how productivity of a(C++) programmer can be measured?
If it is measured by number of code lines per day,
By that measure, my productivity is often negative. I consider those to
be very good days.
You ... refactorer, you!
A mis-reported legend of Microsoft's early years: They did a joint project
with IBM, somewhere in England, and those wacky youths got in trouble with
the IBM fuddy-duddies for everything from coffee makers on their desks to
negative line counts. After finishing a feature (and pumping up the count),
they would refactor and minimize things, and the count would drop again. IBM
probably employed entire resources to track these numbers, and they were not
amused.
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
> probably employed entire resources to track these numbers, and they were
not amused.
Masses of aces.
// Last word's spelling is probably incorrect :-)
"N4M" <dn******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om... Dear,
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)?
Sutter's currently able to produce about 250 lines of code per hour.
Meyer's a close second, at 220, and Stroustrup's trailing behind at about
100 lines per hour. Meyer is working on his typing skills, so it is
expected that his productivity will soar very soon. Stroustrup is focusing
on the next revision of the standard so he can gain a surprise boost when it
is released. Stay tuned for more productivity updates on The Programmer
Racing Channel.
--
David Hilsee
> > estimated productivity of a programmer at beginer, intermediate (Me), advance, master, guru,and sifu (B.Stroustrup, H.Sutter, S. Meyer)?
WTF is "sifu"?
David Hilsee wrote: Sutter's currently able to produce about 250 lines of code per hour.
Meyer's a close second, at 220, and Stroustrup's trailing behind at about
100 lines per hour. Meyer is working on his typing skills, so it is
expected that his productivity will soar very soon. Stroustrup is
focusing on the next revision of the standard so he can gain a surprise boost when
it is released. Stay tuned for more productivity updates on The Programmer
Racing Channel.
hehehe - look up "Novel Writing" by Monty Python ;-)
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
Simple formulas...
Developer + cubicle (noise, distractions) = nonproductive
Developer + newest compilers or latest tech fads = nonproductive
Developer + quiet office = productive
Developer + standard tools and compiler that she's/he's used for the last
few years = productive
A good developer will take more time to do a job right the first time around
(measure twice, cut once). Basically, you get what you pay for, and that
includes allocating enough time for a developer to write good code.
"N4M" <dn******@yahoo.com> wrote in message
news:6e**************************@posting.google.c om... Dear,
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.
NguyenMai
P/S: Similar post has been sent to comp.lang.c++.moderated (probably
takes longer time)
"Phlip" <ph*******@yahoo.com> wrote in message
news:rH****************@newssvr17.news.prodigy.com ... Phlip wrote:
David Hilsee wrote:
...on the next revision of the standard so he can gain a surprise
boost when it
is released. Stay tuned for more productivity updates on The
Programmer Racing Channel.
hehehe - look up "Novel Writing" by Monty Python ;-)
http://www.ibras.dk/montypython/finalripoff.htm#Novel
Now _that's_ funny. :-)
--
David Hilsee
Pete Becker wrote:
By that measure, my productivity is often negative. I consider those to
be very good days.
We only count the amount of code removed as a measure of productivity.
The one who removes the most is given the title "Edward Scissorhands". dn******@yahoo.com (N4M) wrote in message news:<6e**************************@posting.google. com>... Dear,
May I ask how productivity of a(C++) programmer can be measured?
You can ask, but about the only accurate answer I know is
"subjectively."
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)?
Ultimately, what you want to measure is the value of what is produced.
Line counts have already been sufficiently excoriated to render my
doing so superfluous.
Feature counts have been suggested as an alternative, but IMO, they're
only marginally better in most cases. The problem is that a poor
design will often be composed of a large number of discrete features.
A better design will tend to have fewer features, but each will be
more general and they'll work together better -- in fact, the ability
to "compose" features is often the most important feature of all.
As such, when looking at a significant piece of code, the feature
count will often have about the same significance as the line count
(in fact, the two often roughly mirror each other).
Unfortunately, most other objective measures seem little or no better,
at least to me. People have been studying software metrics of various
sorts for decades now, but I've yet to see one that impressed me as
being even close to as good as a pair of experienced eyes looking at
the code. One of the major problems is that while many software
metrics do reasonably well for specific types of code, most of them
run into major problems for other types of code.
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.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On 10 Aug 2004 14:28:32 -0700, jc*****@taeus.com (Jerry Coffin) wrote:
[snip]
Feature counts have been suggested as an alternative, but IMO, they're
only marginally better in most cases. The problem is that a poor
design will often be composed of a large number of discrete features.
A better design will tend to have fewer features, but each will be
more general and they'll work together better -- in fact, the ability
to "compose" features is often the most important feature of all.
As such, when looking at a significant piece of code, the feature
count will often have about the same significance as the line count
(in fact, the two often roughly mirror each other).
What about "feature creep"?
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.
--
Bob Hairgrove No**********@Home.com
That '3rd attempt is gold' is what should be done. It's like writing a
magazine article -- the first time through is a rough draft, then you go
over it and use better words in some places, fix the parts where you're
taking too long to get to the point, and you end up with a working copy. The
third time around, you do more tweaks to the article, and then you have
gold.
Developing software is the same way. Reworking your code 3 times is part of
a *single* process, and if you're not given enough time and the correct
environment to complete the entire cycle, then that code will,
understandably, be subpar for what you can really produce.
However, in the real world (business run by the whims of marketing), the
focus is usually placed on producing software in rapid quantity, not
quality. So I guess the original question of how to measure Productivity
isn't going to have a single answer, because each company has its own goals
in terms of software production -- they either want so-so software shoved
out of the door once every 6 months so that a fresh version is always on the
shelves, or they want to spend a year to make it as reliable and usable as
possible.
"Pete Becker" <pe********@acm.org> wrote in message
news:41***************@acm.org... ChadBl wrote:
A good developer will take more time to do a job right the first time
around
I consider myself a good developer, and I generally that I do the best
job the third time around. The first two attempts are mostly for
learning.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
On Mon, 9 Aug 2004 12:11:57 UTC, dn******@yahoo.com (N4M) wrote: Dear,
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.
NguyenMai
P/S: Similar post has been sent to comp.lang.c++.moderated (probably
takes longer time)
The productivity of "a programmer" can be measured by any number of
factors. The only useful measurements, IMO, are the features added,
the quality of the code, the quality of the product, and the problems
found in the field (negative, of course).
I would certainly hope that your goal for the day is not to write
100 (or whatever amount of) lines of code. I would hope that at whatever
skill rating you are at, that there is a plan to accomplish a certain
number of tasks in the coming days and that you have a specific few to
accomplish in your next session. Sessions can consist of coding, designing,
documenting, verifying, or whatever mix is reasonable.
At the low end I would expect the developer to spend time deciding what
relatively small task to accomplish, how to accomplish that task, testing
and verifying that the code works, and then perhaps rewriting it into a
form that could be used in the desired project. Once complete, another
task or so could be added.
Experience and accumulated tools can enhance the size of the tasks
accomplished. The more advanced developers would show that they can
combine a larger number of tasks and relationships and design ever larger
projects, and then build the project in pieces that make sense for the
overall project. Its also helpful to be able to document the design
so that others might be able to help create the overall project.
David
"Peter van Merkerk" <me*****@deadspam.com> wrote in message
news:2npan1F34rt7U1@uni- Lines of code is the worst metric to measure a programmers productivity.
It stimulates wrong behavior; you don't want programmers to maximize the
number of lines of code to accomplish a certain task.
Good point. Consider the concept of refactoring. Writing un-refactored
code usually leads to code harder to maintain, yet it is easier to write.
Writing factored code is more difficult, yet the resulting code is shorter
and easier to maintain.
Often, to refactor we will write out the main generic algorithm and capture
the specific details varying between specific algorithms as small virtual,
template, or parameterized functions.
Siemel Naran wrote: Good point. Consider the concept of refactoring. Writing un-refactored
code usually leads to code harder to maintain, yet it is easier to write.
Writing factored code is more difficult, yet the resulting code is shorter
and easier to maintain.
One can make refactoring slightly easier by deliberately seeding a design
with a bit of cruft, then taking it out.
For example, to pass a test, you make the minimum edit. Don't yet reconcile
the new ability with all the existing code. If you need to clone an entire
function and change one line, if that passes the test, do it.
When you get a green bar, you are free to clean up the design. Perform
minimal Extract Method Refactors on the common code in those two functions,
and write new little delegating methods. The two lines you change are now
all that's left-over. Give this situation a better structure, and /voila/:
You have a new design. And you might not notice just when growing that new
design involved other regions of the code.
(From here, see my "Contractive Delegation" post now showing on a
news:comp.object near you.)
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
"Phlip" <ph*******@yahoo.com> wrote in message news:55iSc.690 Siemel Naran wrote:
Good point. Consider the concept of refactoring. Writing un-refactored
code usually leads to code harder to maintain, yet it is easier to
write. Writing factored code is more difficult, yet the resulting code is
shorter and easier to maintain.
One can make refactoring slightly easier by deliberately seeding a design
with a bit of cruft, then taking it out.
For example, to pass a test, you make the minimum edit. Don't yet
reconcile the new ability with all the existing code. If you need to clone an entire
function and change one line, if that passes the test, do it.
When you get a green bar, you are free to clean up the design. Perform
minimal Extract Method Refactors on the common code in those two
functions, and write new little delegating methods. The two lines you change are now
all that's left-over. Give this situation a better structure, and /voila/:
You have a new design. And you might not notice just when growing that new
design involved other regions of the code.
(From here, see my "Contractive Delegation" post now showing on a
news:comp.object near you.)
Is there anything wrong if we write factored code from the start? For
example, if I know in my initial design that I want to support both yearly
and transaction items, then I can immediately write an item class, then
derive transaction and yearly item from it. Any harm?
In a similar manner, I may make functions inline before profiling. For
example, std::complex::real() 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.
Siemel Naran wrote: In a similar manner, I may make functions inline before profiling. For
example, std::complex::real() 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.
Low level code details (exception safety, const correctness, smart pointers,
copy operators, namespaces) can't be tested-first. Just write them.
In the case of "inline", you mean writing member function definitions inside
their classes. So answer this: Why are the classes in header files? Do you
have any classes in header files that could be in .cpp files?
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
Siemel Naran wrote: Is there anything wrong if we write factored code from the start?
In pure TDD theory, yes. In practice, if I write the same program three
times, the third time needs less screwing around, and the result's still
better. Upfront planning works the same.
For
example, if I know in my initial design that I want to support both yearly
and transaction items, then I can immediately write an item class, then
derive transaction and yearly item from it. Any harm?
Those are features. Yes there is harm.
Given a hard problem, TDD generates a solution, with a firm design hosting
flexible bug-free features, sooner than expected. This is why Agile
processes fear too much abstract design planning. Complexity that's too easy
to add becomes hard to remove.
"Designing" means organizing the relations between the structure of objects
in memory and their behavior in time. Structure is bone, behavior is muscle,
and perfecting their design is difficult. The best way to seek simplicity is
to start with it.
The most important kind of duplication to fold is definitions of behavior.
Folding them together forces structures to grow new flexibilities. Mature XP
projects do _not_ refactor mercilessly, despite engineers are _required_ to
refactor when they see poor code quality. They don't. Adding new features
requires extending the existing design, just as if it had been brilliantly
planned.
These pressures force code to follow a curve of minimum complexity. Add a
feature, and the code puffs up. Air bubbles form in it.
If you then add another feature, the air bubbles harden, becoming more
difficult to remove.
If you instead refactor to force out any speculative code, the effect is
like hitting your substance with a big heavy hammer. You crush out all those
air bubbles. When you add the next feature, it has less chances of more air
bubbles, and less chances of them hardening.
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
On Wed, 11 Aug 2004 05:51:37 UTC, "Siemel Naran"
<Si*********@REMOVE.att.net> wrote: "Phlip" <ph*******@yahoo.com> wrote in message news:55iSc.690 Siemel Naran wrote:
Good point. Consider the concept of refactoring. Writing un-refactored
code usually leads to code harder to maintain, yet it is easier to write. Writing factored code is more difficult, yet the resulting code is shorter and easier to maintain.
One can make refactoring slightly easier by deliberately seeding a design
with a bit of cruft, then taking it out.
For example, to pass a test, you make the minimum edit. Don't yet
reconcile the new ability with all the existing code. If you need to clone an entire
function and change one line, if that passes the test, do it.
When you get a green bar, you are free to clean up the design. Perform
minimal Extract Method Refactors on the common code in those two
functions, and write new little delegating methods. The two lines you change are now
all that's left-over. Give this situation a better structure, and /voila/:
You have a new design. And you might not notice just when growing that new
design involved other regions of the code.
(From here, see my "Contractive Delegation" post now showing on a
news:comp.object near you.)
Is there anything wrong if we write factored code from the start? For
example, if I know in my initial design that I want to support both yearly
and transaction items, then I can immediately write an item class, then
derive transaction and yearly item from it. Any harm?
<snip>
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.
David
"N4M" <dn******@yahoo.com> wrote in message 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.
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";
...
}
Siemel Naran wrote: 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.
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...
So how about:
int main() {
std::cout << "hello world!\n";
std::cout << "hello world!\n";
You cheat! You didn't write them, you copied them!
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
David wrote: 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.
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/bi...UserInterfaces
Hi Phlip,
On Thu, 12 Aug 2004 09:38:03 UTC, "Phlip" <ph*******@yahoo.com> wrote: David wrote:
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.
There are those who think planning designs causes bugs, and lowers
maintainability.
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.
So, how much time do you spend debugging? And how well have modules written
like this been re-used and maintained over time?
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
"Phlip" <ph*******@yahoo.com> wrote in message news:gSGSc.3032 All interview questions reveal something about the hiring company...
Such as?
Siemel Naran wrote: Phlip wrote:
All interview questions reveal something about the hiring company...
Such as?
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/bi...UserInterfaces
Bob Hairgrove <in*****@bigfoot.com> wrote in message news:<kd********************************@4ax.com>. ..
[ ... ] What about "feature creep"?
It sucks. What else can be said? :-)
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.
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.
Jerry Coffin wrote:
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.
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.
Siemel Naran wrote:
In a similar manner, I may make functions inline before profiling. For
example, std::complex::real() 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.
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.
"lilburne" <li******@godzilla.com> wrote in message
news:2o************@uni-berlin.de... Siemel Naran wrote: In a similar manner, I may make functions inline before profiling. For
example, std::complex::real() 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.
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.
Even if it just returns a member variable by value?
lilburne wrote: Siemel Naran wrote:
In a similar manner, I may make functions inline before profiling. For
example, std::complex::real() 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.
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.
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/bi...UserInterfaces
Siemel Naran wrote:
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.
Even if it just returns a member variable by value?
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.
Phlip wrote:
If you inline all methods inside classes unless profiling reveals the need
to outline them, your code is more cognitively efficient.
Nah! It just clutters up the thing making it impossible to
read. I want to see API not implementation.
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.
Don't you just hate it when that happens, and 20% of the
time the dependency is spurious anyway.
lilburne wrote: Phlip wrote:
If you inline all methods inside classes unless profiling reveals the
need to outline them, your code is more cognitively efficient.
Nah! It just clutters up the thing making it impossible to
read. I want to see API not implementation.
And... it... makes... it... look... like...
====> JAVA <====
AAAAAUUGGGGHHHH! Run screaming!
--
Phlip http://industrialxp.org/community/bi...UserInterfaces
"lilburne" <li******@godzilla.net> wrote in message
news:2o************@uni-berlin.de... Siemel Naran wrote: Even if it just returns a member variable by value?
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
All my compilers let you debug inline functions (Borland 6, MSVC 7, MSVC 6,
gdb g++).
Siemel Naran wrote: "lilburne" <li******@godzilla.net> wrote in message
news:2o************@uni-berlin.de...
and within the A.i file you write
#ifndef OUTLINE
inline A::A(int i) : m_i(i) {}
#endif
All my compilers let you debug inline functions (Borland 6, MSVC 7, MSVC 6,
gdb g++).
Hmmm! Can you set a breakpoint or just step in?
"lilburne" <li******@godzilla.net> wrote in message
news:2o************@uni-berlin.de... Siemel Naran wrote: All my compilers let you debug inline functions (Borland 6, MSVC 7, MSVC
6, gdb g++).
Hmmm! Can you set a breakpoint or just step in?
Both, at least on Borland 6! I just tried to set a breakpoint. I put
breakpoints in non-template functions. My file structure is: source code in
src\libname\file.cpp, and the headers are include\libname\various.hpp. Put
a breakpoint in any of the various files in the include directory, and the
debugger will hit the breakpoint. Thinking about it, I think that in debug
build the compiler makes all functions non-inline, so of course you should
be able to step through it. Presumably if you debug the release .exe or
..lib or .dll, stepping through individual assembly instructions, you won't
hit the breakpoint because if the code is really inline it won't be in the
..exe. Anyway, I don't have the bandwidth to test this.
Nevertheless, the rule about making all functions non-inline unless
profiling says to do so is a good one. I break the rule so that I don't
have to write lots of little short get/set functions in the cpp file. It's
a timesaver, and worth it. Though by the premise of the original post of
this thread it means I'm un unproductive programmer because I have fewer
lines of code :). However, if I have a file that has just one get/set
function, while the rest are long functions defined in the cpp file, then
I'll make the one get/set function pair (two functions), non-inline and
defined in the cpp file, just for consistency with the other functions.
Siemel Naran wrote: "lilburne" <li******@godzilla.net> wrote in message
news:2o************@uni-berlin.de...
Hmmm! Can you set a breakpoint or just step in?
Both, at least on Borland 6! I just tried to set a breakpoint. I put
breakpoints in non-template functions. My file structure is: source code in
src\libname\file.cpp, and the headers are include\libname\various.hpp. Put
a breakpoint in any of the various files in the include directory, and the
debugger will hit the breakpoint. Thinking about it, I think that in debug
build the compiler makes all functions non-inline, so of course you should
be able to step through it. Presumably if you debug the release .exe or
.lib or .dll, stepping through individual assembly instructions, you won't
hit the breakpoint because if the code is really inline it won't be in the
.exe. Anyway, I don't have the bandwidth to test this.
Probably some weirdness in the linker too to make it work
across libraries.
Nevertheless, the rule about making all functions non-inline unless
profiling says to do so is a good one. I break the rule so that I don't
have to write lots of little short get/set functions in the cpp file. It's
a timesaver, and worth it. Though by the premise of the original post of
this thread it means I'm un unproductive programmer because I have fewer
lines of code :). However, if I have a file that has just one get/set
function, while the rest are long functions defined in the cpp file, then
I'll make the one get/set function pair (two functions), non-inline and
defined in the cpp file, just for consistency with the other functions.
Consistency is a good thing. Personally I prefer not to have
implementation details in the headers just the API. I can
just about tolerate member variables, but to each their own.
I prefer to look in just one place (the source file) for
implementation rather than first looking in the source and
then having to go to the header. Anyone equating LOC and
programmer productivity is talking out of their arse.
"lilburne" <li******@godzilla.net> wrote in message
news:2o************@uni-berlin.de... Consistency is a good thing. Personally I prefer not to have
implementation details in the headers just the API. I can
just about tolerate member variables, but to each their own.
I prefer to look in just one place (the source file) for
implementation rather than first looking in the source and
then having to go to the header. Anyone equating LOC and
programmer productivity is talking out of their arse.
You can have member variables in the cpp file. Look up the pointer to
implementation concept, where in the header you declare for example a nested
struct Imp, give your class a pointer or smart pointer to this Imp, and
freely define it in the cpp file. You insuluate derived classes from length
recompiles, plus you can easily add reference counting to your class now.
What is LOC?
"lilburne" <li******@godzilla.net> wrote in message
news:2o************@uni-berlin.de... Siemel Naran wrote: Hmmm! Can you set a breakpoint or just step in?
Both, at least on Borland 6! I just tried to set a breakpoint. I put
breakpoints in non-template functions. My file structure is: source
code in src\libname\file.cpp, and the headers are include\libname\various.hpp.
Put a breakpoint in any of the various files in the include directory, and
the debugger will hit the breakpoint. Thinking about it, I think that in
debug build the compiler makes all functions non-inline, so of course you
should be able to step through it. Presumably if you debug the release .exe or
.lib or .dll, stepping through individual assembly instructions, you
won't hit the breakpoint because if the code is really inline it won't be in
the .exe. Anyway, I don't have the bandwidth to test this.
Probably some weirdness in the linker too to make it work
across libraries.
I think the reason is that I compiled my library parse.lib in debug mode
into a debug lib file. Then I compiled my example.exe, and linked against
the debug parse.lib file, and I was therefore able to put breakpoints in the
inline function. Had I linked against the release parse.lib file, that
would probably not have been the case.
In the past, I found that creating a release parse.lib file, then compiling
example.exe in debug mode and linking against the release parse.lib file
caused my program to mysteriously crash at runtime. The reason I think is
that the class headers of the parse library define STL member variables,
like std::string, std::deque, etc. The parse.lib compiled in release mode
links against the release STL files, performs various compiler
optimizations, etc. My example.cpp includes the same headers, but compiles
in debug mode, so it does not do various optimizations, assumes that the
parse.lib file will link against the debug STL files, etc. So if both
parse.lib and example.exe are compiled in release mode, or both in debug
mode, then it works fine.
When I get more time, I'm going to use the pointer to implementation idea,
and define a nested struct Imp, and define it with all the STL member
variables in the cpp file. This might allow me to compile and run a debug
example.exe linked against a debug parse.lib. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: kbass |
last post by:
In different articles that I have read, persons have constantly eluded to
the productivity gains of Python. One person stated that Python's
productivity gain was 5 to 10 times over Java in some in...
|
by: bruce_taylor |
last post by:
Please forgive me if this is a little off topic, but I'm trying to
reach a population of active programmers and this newsgroup is an
popular gathering place.
I am conducting research on the...
|
by: Claudio Grondi |
last post by:
In todays posting
"Any wing2.0 users here?"
I found in the sentence
"What can you say about this IDE? He say's 'if I think it could
improve my productivity he's willing to buy it for me."
the...
|
by: Connelly Barnes |
last post by:
Hi Python folks,
I created a summary PDF of two studies on programming language productivity:
http://barnesc.blogspot.com/2006/05/programming-language-productivity.html
One notes that Python...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
