Quote “the studies I’ve ever seen suggest that the average programmer’s number of correct lines of code produced per day is in the order of 20…”
Actually 20 lines of code per day typically also includes documentation
open FILENAME, $filename = 'short_perl.pl' or die 'foo';
print (@bob = );
Come on - it can be done in one line…
print join('',IN) if open(IN,"file.txt") or die("$!");
Don’t complain about not being able to read the code. 
The python one-liner is:
print open("file.txt", 'r').read()
No need to iterate through the lines if you’re going to read them all in at once with .readlines() anyway. Add two or more lines for a try/except clause if you like.
plze i want ask you about to help me to make this program in java
write a program to count (in LOC) the
• total program size
• total size of each of the program’s parts (classes, functions, or procedures)
• the number of items (or methods) in each part
Produce and print
• a single count for the entire program
• size and item counts for each part together with the part name
.
plze answer me in short time.
for completeness, a one line ruby solution:
puts IO.readlines("test.file").join rescue puts "oops..."I like perl and all, but c# inside visual studio.net is the best development platform of all time. It is just so fucking sick, nothing can compare. As much as some people hate microsoft, they sure make programming pleasant.
spreading code out onto multiple lines just makes it easier to read, easier to comment, easier to maintain, and easier to get the project done closer to the deadline. scripting languages are a waste of time if you are trying to do anything important such as hundreds to thousands of pageview per second server farms, or complicated windows applications.
I’m talking applications with over 100,000 lines of source code developed by four to five developers.
I think scripting languages are a great tool for sysadmins though, and programs that munge data and do spidering of web content and things like that.
no, scripting languages are only useful for sysadmins. what else are they good for?
Yes, but… all other things being equal, less LOC is generally better. That’s fewer lines of code to debug, to understand, etcetera.
If you have too few lines of code it becomes harder to understand. Why do some coding standards of good development teams outlaw tertiary syntax? Because it is a pain in the ass to look at.
PLEASE PLEASE PEOPLE DO NOT EVER USE TERTIARY SYNTAX. THAT SHIT IS SO FUCKING ANNOYING TO MAINTAIN.
@previous commenter
There’s nothing wrong with tertiary syntax, you just have to know how to write it clearly. For example, placing it within an if statement or within another tertiary statement would be an example of being unclear. But on a relatively short line, especially one that simply does an assignment operation, there’s nothing unclear about it at all, unless you’ve never seen a tertiary statement before.
It’s actually “ternary”, guys. See the comments here:
If you have a group of coders, how can you really measure their productivity across the group, in order to get a sense of who is lagging behind and encourage improvement? LOC just doesn’t sound like a good measure, because it has nothing to do with the relative usefulness or quality of the code in the end.
How have you all been measured in ways that you thought were fair and useful? Bugs after submission, rework after design, number of features implemented, accuracy of estimated time to implement, etc.?
I think the are other issues, like how easy or fast you can find the module (or example) you are looking for.
I know CPAN is great for fast search of lots of modules, and it is there from the day one , but where do you look for C++ or C# etc?
If the was a C++ CPAN then the story might be diffrent.
neat comparison. i love python and ruby, but i also use c# for scripting. when i saw your 13 lines of c#, i created a new c# script on my desktop …
string filename = "readAFile.cs";
try {
Console.WriteLine(System.IO.File.ReadAllText(filename));
} catch {
Console.WriteLine("Problem with {0}", filename);
}
there’s no reason to over-complicate things. out-of-the-box, i would need class and namespace declarations (+4 more lines). here, i’m using a classless c# file (using c# script).
i code ASP.NET pages, so my c# is typically sharper than any of my other languages … so, when i want to script something, i throw a new .cs on my desktop and code it up and use a scripting engine to run the scripts.
the difference here is really the TOOLS. sure, visual studio always requires namespaces and class declarations, but not all c# tools do. c# is a powerful language and can, when well written, have a simple and easy to read syntax.
dunno. i LOVE ruby and i’ve been using python more and more, but i’m paid to be a c# coder, so that’s what i use most.
Counting 15 lines for Java is really unfair. Using similar tricks as in your C# example (avoid imports, don’t put opening braces on a new line), a Java version can be quite short:
public class ReadAFile {
public static void main( String[] args ) throws java.io.IOException {
java.io.BufferedReader in = new java.io.BufferedReader(new java.io.FileReader("ReadAFile.java"));
String line;
while ((line = in.readLine()) != null)
System.out.println(line);
}
}
That’s six lines if we don’t count closing braces (as for C# and VB above).
A brace can sometimes be a line of code. Take this code snippet, where the ResourceHungryClass instance is in scope for the duration of DoSomethingTimeConsuming().
auto_ptrResourceHungryClass pFoo = new ResourceHungryClass;
pFoo-Bar();
DoSomethingTimeConsuming();
This situation can be resolved by adding braces, and making a change to the lifetiime of ResourceHungryClass:
{
auto_ptrResourceHungryClass pFoo = new ResourceHungryClass;
pFoo-Bar();
}
DoSomethingTimeConsuming();
Not saying that this is good practice, just that the closing brace is as much a line of code as pFoo.release() would be, except the version with braces doesn’t leave the variable in scope (which is arguably safer).
i think, to decide whether brackets count as LOC or not, it is important to look, why we are counting the lines: to get an approximation to the complexity of the code.
LOC may be a good way if you look at big projects, but are hard to interpret if you look at single functions.
For example: what is more complex, a full line of regular expression, or three lines of simple search/replace commands?
A google search on ‘programmers lines of code’ brought me here, and in way has answered my question.
I was looking for a gateway into a discussion of true programmer productivity. Essentially, all the wrong measures are still being used and the idiosyncracies of the language syntax being debated here validate my view. Whether five lines in Ruby or 15 in C++, an experienced programmer in the particular language will knock those out very quickly.
Today’s programs are not built on 5 or 15 or 20 lines of code, but on 40 to 400 to 4000 objects. That is the fundamental block. Having programmed since the late '70’s across most platforms from real-time embedded to client / server applications to today’s web solutions, the logic block has moved from counting lines of code and execution time in microseconds, from designing structures and implementing in ‘lines of code’, to objects and inter-object relations and frameworks.
Spaghetti code does not exist, but rather Spaghetti objects are today’s bane.
So I will put forth a simple definition and a number, as a gut call, and see who bites :
Clean object with a good interface, minimal ties to other objects to prevent support hell, typical programmer documentation on the methods with a simple sample of using the object in the target environment. This is the base for the ‘object’.
How many of these per week?
Let’s start with 1 as my guestimate, with a degree of experience if 'not else, as how many per week.
Journey far and fare well!
Languages and lines of code comparisons are nice. However the only real thing that matters, is how debuggable the language is, and whether or not there is a good means of debugging (i.e. a good debugger.)
Most anything can be done from any of the languages out there, but if you can’t actually debug the code, what does it matter?
Unfortunately the Python code shown is a little crappy. File objects are their own iterator (i.e. for line in f:) and doing a try: …; except: … without a raise is very bad form - MemoryError and KeyboardInterrupt, for example, will both be caught as a problem with the file. Catch explicitly (IOError) instead. Pedantry aside, if the code doesn’t do what it’s actually supposed to do or if it does it particularly badly (reading a whole file into memory before outputting, incorrectly catching exceptions) then how short the code is is insignificant. Moreover it is a disservice (although I’m sure unintentional) to the language to publish examples of it being used badly.