How fast do you code?

How many lines of code do you write AND KEEP on average? In VS there is LoC metric. How fast does it grow for you on average per day?

I know it doesn't matter. I'm just curious.

 

I recommend sublime text over VS for speed :/

 

Speed, clarity, speed, interface, speed, customization, and again, speed. I love Sublime, I've bought it just to support them. It's more than deserved. (And someone put on the official package repo a nice Syntax Highlight for Unity)

Answering Quingu question, I know it's almost irritating to say, but it really depends on too many things. I am a one-man-show, I need to plan, to test, to fix, to create the model, there are too many things that can influence a day of work that I can't really estimate the number of lines I could write if 100% focused on it.

 

I actually code quite slow. Most of the time is spent reading API docs or thinking about what I need to do.

 

Beginner: I wrote 400 lines of code today!
Intermediate: I refactored 200 lines of code today.
Pro: I eliminated 300 lines of code today.

 

Lines of code is a useless metric for pretty much anything.

A 'quick coder' may punch out 1000 lines of code an hour. A 'good coder' may do the same solution in 2 hours with 3 lines of code.

I know which is better. Writing code is simple. Debugging and maintaining code is difficult. More lines of code = more debugging and more maintenance.

 

Not if you have Resharper installed and know most of the shortcuts.
No way Sublime text could be faster for writing C# code.

Also my VS is very performant unless I have a solution open with about 30 .NET projects in it.

 

Whatever your machine is, try to benchmark how fast it is to open Sublime and how fast it is to open VS. Do the same by opening a file having both code editor open. Now try to open 100 scripts on both VS and Sublime, then, after you restarted your machine because VS crashed, tell me if you still believe VS is performant

 

Since none of those match up to an actual use case, what's the point?

I'm pretty slow. I tend to spend most of my time figuring out what to do, and testing what I did do. Actually creating lines of code is pretty quick.

But I've never actually paid attention to lines per hour/day/week. So I can't say for sure.

 

The point is that it is simply not true that VS is faster than sublime, whatever language you are using. You can argue that it has less pre-defined function or that you are more comfortable using VS; but stating that is faster for coding C# without any space for discussion it is simply not true.

 

I average about 5 punching-the-computer-screens per hour.

--Eric

 

A wizard is never redundant, nor are they inadequate. They type precisely what they mean to.

 

The bench test you suggested doesn't actually measure coding performance or productivity though. Sure sublime opens faster then visual studio. But how many people open an IDE more then once during a work day? Sublime might save you 30 seconds over a day.

Opening 100s of scripts at a time is another unlikely scenario. It just doesn't match up to what a programmer does in the average day.

So if you want to argue Sublime over VS, pick a set of conditions and tests that programmers actually do. Look at the speed of creating a new class or refractoring a major system. Look at the autocomplete features or the templates. Look at anything that actually speeds up the average programmers day.

Disclaimer: I'm not working full time as a programmer. There may well be programming jobs that consist of simply opening and closing the IDE. In which case ignore this post.

 

Who cares how fast scripts open and close. I care about how fast I can get the code in my head onto my computer.

 

For me getting code from my head to the computer is not the bottleneck. Its getting the code in my head that takes the longest.

 

You know what a fun thing? Come up with a basic idea of a game, and then start typing. Don't stop for more than 10 minutes at a time. Continue until game is finished.

Point is that I think for a lot of us, coming up with elegant code and spending a lot of time planning systems is largely a waste of time. Once you've been around games for a while, many of the approaches to different things are familiar, and it's just a lovely distraction to go around planning it like you're trying to come up with something new. It's mind-blowing how much you can get done if you think to yourself "well, I'll just entertain myself for a little while and see what happens if I just put one foot in front of the other" and suddenly all this stuff that usually takes weeks, comes out like it's nobody's business.

 

I'd probably die before any game was finished. 10min - when can I sleep? I heard a rumour that 6 months without sleep can be detrimental for ones health. I call shenanigans, but I'm not an expert on sleep deprivation!

 

Hehe, I didn't mean without sleep - I meant, don't stop typing while at your desk with the editor open.

The thing is that (at least for me) it's an ongoing battle to stop obsessing about architecture and planning. I can easily sit there for 20 minutes with a vacant look in my eyes just wondering whether it's best to access a variable from one script or the other.

And it's not even just the actual planning, but the feeling of for example being about to add a big new game mechanic, there's a tendency to just sit there and 'make sure' you know what you're going to do for hours on end.

I've had the idea on and off for a long time, that the best way to do things is to throw paint around (so to speak) and clean up the mess at the end of the day. When you're not second-guessing yourself and just building as you go it's incredible how much of the structure of the code you can hold in your head, and how easy it is to deal with roadblocks that would otherwise mean a few days of 'rest and replanning'.

 

Been there. Done that. Doesn't work. For me at least.

 

Around 5 screens *change* or are added a day, as a heck of a lot of my work isn't actually code but R&D

Sometimes it accelerates if it's a job with clear outcome, I'll finish the job within the hour usually. For what I'm doing though, things dramatically slow down, because it's not quite like other games even if on the surface it appears to be.

 

Partly I think it has to do with the solo dev experience - trying to keep alive both your emotional and logical 'personalities' at the same time. When I have a more unstructured approach to coding, I find that my ability to analyze the fun factor and feel the game flow is much better and that in turn cuts down the coding time. It's like I can almost feel the impact that the code that I'm typing will have on the player experience, as I'm doing it.

Although, I'd kind of hesitate to say that that's all it is. I think it's also a question of, what you train is what gets stronger. If you believe that more organisation/pre-planning is better, or vice versa, that's to some extent a self-fulfilling prophecy, because your skills in that regard will increase and the others will weaken, not to mention confirmation bias.

Of course, it's probably not going to have quite the same relevancy when working in a team or as part of an organisation where coordination is key. It's more of a solo thing, like writing a book or creating a painting.

 

Kind of a weird question.

Especially since after a point in development, you usually tend to end up with less lines of code than what you started with.

Sooo... -10?

 

What project are you working on now, any sneak peeks for the unity forums users?

 

This is quite possible. I do know there are some devs that advocate just throwing code at the screen and seeing what sticks.

For me I found that if I don't plan out a structure early, I end up needing one later anyway. So I typically end up stopping and refractoring everything to make sense of what I've written.

Since I will have to step back and consider the big picture at some point, I like to do it first. It ends up being less work for me.

 

You should care about quality of code and overall game architecture.

There's no point telling how fast or how many lines you code, when the whole entire project has to be re-done again, or code-rewrite.

 

Ranges so much I wouldn't consider measuring it. But in average lets say I've been adding 3 or 4 .js scripts to my project every week. Though that's useless information.

A real measurement would be to give a programmer some sort of uncommon coding task, something that's not familiar to him, and see how long it takes to do it. That would be a better speed measurement.

There could be a follow up test that measures how able the programmer is to perform X changes on that project (maybe wait several months for this test, so he forgets how he did everything lol) and measure how manageable his code is.

 

500 a day is doable but like others have mentioned: it depends.

For example: Assembly will be times > c#/c++/java as you have to think of memory addresses all the time and then it depends on the effectiveness of the code, for example both are the same but different in lines of code, sometimes instead of putting the same action in a class and just call it, new devs will write the fundtionality over and over again.

 

I'm working on an action adventure, the art is being done so unless you want placeholders there's not much point

Yeah I find myself just thinking "I'll get the functionality down then refactor it to make sense of it later..."

 

What you are saying is true 100%, beyond any doubt, the distinction I was making and that I probably didn't explain well enough is that there is a substantial difference between "coding speed" and "software speed". While the second one can be measured and tested, the first one is highly subjective and depends on programmers history, preferences, and user cases. You can say you prefer VS for the reason you want, and that's totally fine, but saying "No way Sublime text could be faster for writing C# code." no, it's something you can't say

 

That's pretty much my approach. Once something works, even if it only works badly, it's still a point where you can sort of 'cruise along' for a while and clean things up. Lately though, I'm trying to develop a better set of habits so that I don't make so much of a mess.

 

Thing is, refactoring takes time, and you do it when it will save you time, usually this is when you need to insert more complex relationships. A black box function that's a mess but does one thing rarely ever needs refactoring.

Typical things I refactor include AI, controllers, systems and behaviour - the stuff that gets pretty messy, not the project which should really be quite clean anyway given Unity's component driven methodology.

 

I code as slow as possible so as to not make spelling mistakes and so i follow the syntax correctly, my slow approach usually gets me around 500-700 lines of code depending on the complexity of my game.

 

The moral of the story kids, more lines of code just means more places for bugs. It doesn't matter how fast you code if you haven't tested it fully, or if you don't understand how it's structured. Programming is about a lot more than filling a text file with symbols.

 

As fast as I can scrape together pennies for assets and then very, very slowly with two fingers and a the patience to wait for auto-suggest to suggest for a massive half dozen or more APIs

 

Guilty here as well. I definitely prefer to overplan everything. It does result in really well running code, though.

 

I plan the minimal architecture necessary to start coding then I tend to code iteratively implementing and perfecting code maybe 5 times before it reaches it final state.

Also IMHO Unity coding is quite different from classical coding, and once you start using Unity the way it is designed to be coded you kind of reach a "Karma state " where you progress surprisingly quickly. For an example I do intensive use of components and interfaces to share functionalities and refine and complete gameobjects that are part of my game.

For coding I love Script Inspector as it allows for very quick iteration without even leaving Unity Editor saving probably 20-30 seconds for each iteration.

 

Well-running, but not enough of it by a long shot.

 

I don't like like lots of lines of code or lots of files.. its just more to read and go through.. I guess its why I have a loathing hate for C++ for its additional header files.. Saying that at some point my files do grow large enough that there is enough functions and logic that can be grouped and put into another file of its own but otherwise I have a some files with 1000lines all grouped with region markers...and I kinda hate it a bit as VS codemap scrollbars becomes a bit more useless for code navigation.. (maybe VScode will be less rubbish to use for me when they add native support for a codemap scrollbar its not like the biggest requested feature, VS startup performance isn't great when you open up multiple unity projects and it loads up a different VS instance to check something.. kinda gets annoying where something lightweight like VScode would be better, ofc then I'd want that preference to be a per project setting)

Anyway as a comparison I have one .cs file that was implementing a connected component labelling algorithm and the original git commit for that was around 200lines.. I think you really do have to write terrible code even if it is just too get something started, you can spend all day thinking about and trying to research what the best and most efficient and performant way to do something would be, but until you actually just start inputting that code at your own level of competence for your own project requirements and get something working even if its not perfect or has bugs.. its still making progress. You later go through and see where the bottlenecks are in performance and optimize as you go...

Half way through where I had the algorithm somewhat working the file was 250lines,and on an array of 10k it was taking 8seconds too process... did I say it was terrible code. (this was for 3d voxels so essentially it was around 60k checks for 10k blocks)...few commits later, and I've deleted about 150 lines and rewritten about 100, at this point the same 10k array is down too around 800ms...still not good. I have it now at ~20ms and its reduced alot more if certain conditions are met in the array, at this point the .cs file is around 190lines and does all that I need it too for the game, with all the bugs fixed, I've still got too make it work in a multithreaded queue system where something like 20ms isn't spiking the main game. Anyway short of counting the added and deleted lines and manually going through each git commit I couldn't say what my average lines of code was, but I don't think average lines of additional code is a good indicator of anything more than you did something.

 

I'm not sure how, but it seems the thread went from speed to number of lines. I think there's a huge difference - speed is certainly an arguably good thing but number of lines is not. Speed may result in superfluous code but I don't see why it's a necessary causation.

 

It started as number of lines....

--Eric

 

You can actually just put all your code into the header files in C++.

I'm most certainly not arguing that's either a bad or good idea.. But technically doable.

I must apologise, I'm am a C++ fan, love the language (was my go-to for many-many-many years) - but I agree the maintenance of header files is a tedious bore after using more modern languages like c#.

Note, I'm quite a fan of C# too - so not overly biased.

 

My bad, I was going by the title ... so I guess 'how fast can you code' means 'how fast does your codebase grow'. I don't think that's a very good way of looking at things, but there you go.

 

Well, it would make a good case for manually unrolling loops and using lots of copy & paste.

--Eric

 

"Write and keep" wouldn't normally be measruable per-day for me. My "write lots of code" days and my refactoring days tend to be separate things. At a little over a month into the project (and definitely not full-time), VS counts 13,999 lines of code. But I've also done a lot of the UI graphics, I actually use written designs (gasp! ... about 21 pages of that), etc., so it's far more than LoC.

I'll say this much, I'm much faster knocking out Unity code than slogging through my boring financial-database day-job projects. For those, simply staying awake is part of the challenge.

 

Did you write 14k lines in a month from scratch? IMO that's a HUGE amount of code per month. I'm currently averaging 1.5k per month after 4 months.

 

My totally inaccurate summary....

> +10000 lines code, someone who's just found someone else's API framework to add to the project.
> +1000 lines of code, Pro with no internet connection, possibly tied to a desk living on pizza.
> +100 lines of comments and summary text, someone trying to avoid writing code.
< 10 lines of code, someone trying not to write code at all.

 

Yeah but it's also a text-heavy game, lots of string building to describe battles, that kind of thing.

Apparently VStudio's LoC metrics aren't very reliable -- it "estimates" from IL, somehow.

 

If one was being pedantic one could argue that is data and not code (but I'd *never* be pedantic )

A semi-colon count is typically a better metric for lines of 'code' (caveat: for languages that use semi-colon as a statement terminator). I expect most of us would not equate lines with just braces on them as a line of code, etc. Some of us also break statements over many lines - which for the point of metrics is really a single statement spread over lines.

But IMO all these types of metrics are pointless - the express more about a persons coding style and approach to solutions. What's more important is how much 'product' is produced. Software Engineering houses can use things like 'requirements implemented' and such metrics - which *can* be useful *if* the requirements are well formed and decomposed in a quantifiable manner.

But even these metrics are somewhat useless at the micro level - for a project whole (macro level) they are useful 'guides' but for any individual piece of work they are useless (unless they can guess how many bugs will be included and how long it takes to solve said bugs etc).

I produce exactly the amount of code I can per day. No more, no less. So I'm 100% efficient!

 

It's not the size of your code its what you do with it that counts!

 

That's only ever said by people with small code

Spoiler: Not really true, but it was too good to miss.

...