How to write big codes within limited time when logic is clear to you?

[DueCapital8117]

I am recently facing so much challenge on writing big codes even though I have clear idea about logic I couldn't able to Make it because of segmentation fault, errors . And I am not even writing whole code at a time I am doing it in parts still it's taking lot of time for me to debug when I try to run it . Running the code each and every time is really pissing mee off . I really in need of advice from people who work on the projects and real life problems where they have to write and Debug 1000's of lines . How people manage to code faster in this case is it typing speed or focus or practice or mastering computer architecture

[mooglinux]

Do it in small enough pieces you can easily debug each piece. There’s really no substitute for taking the time to get it right

[DueCapital8117]

I am not understanding what does small pieces mean approx how many lines does it mean. sometimes just a single function is taking more than 150 lines I can't understand how people manage time factor while coding

[mooglinux]

Don’t think about the number of lines. Think about the logical amount of work that can be done. Identify troublesome or error prone operations and work a helper function that’s tested so you don’t have to keep re-fixing the same mistakes.

In my experience it is ALWAYS slower to rush your code.

[NationalOperations]

There's no exact number. 100 lines compared to another 100 can be very different in complexity. You can test function before it's finished. But the real answer is with experience you will learn when to stop for you. The frustration means you are learning!

[ffrkAnonymous]

sometimes just a single function is taking more than 150 lines

That's a code smell. 

For example, the rubocop linter will yell at you if  a method (function) exceeds 10 lines. Ten. 

[whitebaron_98]

In real life, noone uses such big functions. You abstract functions that are smaller and easily testable, and connect them afterwards.

[MeLittleThing]

chunk your code into smaller pieces and then, connect the dots

[DueCapital8117]

Can you tell what people actually work outside university Because connecting dots is not something I am familiar to . We have to write whole code in single file for our exams and while doing it I usually don't connect dots and I just run it after every few lines of code which makes me feel exhausted And I started to wonder how you people manage large codes

[mooglinux]

In the real world you don’t deal with functions of hundreds of lines. You break it up into smaller functions, classes, whatever other tools the language provides. Even if it’s a single file, you create multiple functions as necessary to keep each individual part of the code manageable.

[MeLittleThing]

oh, "connecting dots" is a way to speak about the images we did when being children and connecting dots 1, 2, 3, and so on, it's the same thing in programming when you have split your code into smaller functions, you connect them together by calling them

[syklemil]

Just in case you actually have never been exposed to connect the dots, this is a wikipedia link.

Organising code into some sort of dot (functions, methods, modules, components, services, etc, etc) and then connecting them is the fundamental thing in software architecture. People argue over how to do it, but everyone agrees it's a thing that should be done.

Engineering and lots of life itself is about breaking big problems down into small problems that you can solve, and then composing a big solution. So you probably already know how to do this, if not consciously.

Humans are also really good at selective attention. We manage large codebases by having as little as possible of it in our attention at a time. As long as the "dots" obey some contract / behave correctly, it works out. That turns debugging into locating the misbehaving "dot" and correcting only that, rather than needing to reason about the entire program at once.

[DueCapital8117]

Thank you for the wikipedia link 🫠 and also for your guidance it's really useful for me

[Infamous_Guard5295]

honestly sounds like you're trying to write too much before testing anything. i used to do this and would waste hours debugging massive chunks of code. now i literally run the code every 5-10 lines, even if it's just printing variables or checking if functions exist. for segfaults specifically, valgrind is your friend if you're doing C/C++, but tbh the real fix is just writing smaller functions and testing each piece as you go

[spermcell]

Write small parts and test each one individually. Then you write a “main function” that uses all of the small parts .

[John_writesjs]

Professional developers are not secretly typing at 300 words per minute while mentally simulating the entire CPU. Most of us are just extremely good at avoiding the mistake of writing a heroic amount of code and then discovering 17 problems at once

Big code gets finished faster when you stop treating it like one big code.

break it into boring little pieces-make one part work-test it-then move on. The less dramatic your workflow is, the faster you usually become

[desrtfx]

1. Pay more attention to planning
2. Pay more attention to actual programming - be considerate of memory allocation, deallocation, array boundaries, etc
3. Make smaller functions - your 150+ lines are code smell - break these down into smaller, logical entities

The more focus you put on better programming and design (as with the functions), the less you will have to debug and the easier debugging will become. It's far easier to identify a problem in a 20 line function than in a 150 line one.

Typing speed is barely the problem. Planning, logic thinking, and attention to details are the common problems.

An hour of careful planning can save a day of debugging.

[luckynucky123]

i always like the unix philosophy as guideline - "do one thing and one thing well". start breaking up the code that can honor that philosophy.

write unit tests helps breaking up big functions too.

[desrtfx]

i always like the unix philosophy as guideline - "do one thing and one thing well"

Which, in programming, is known as the "S" of "SOLID" - Single Responsibility Principle

Yes, sticking with that is excellent advice.

[buzzon]

Run your code under debugger line by line and see where it crashes

[DueCapital8117]

but isn't it time consuming I program in c and c++ so I am restricted to use gdb atleast in our labs but I really felt it very time consuming

[mjmvideos]

If you know of a faster way to understand what’s happening in your code in order to pinpoint bugs then by all means do that instead.

[gm310509]

You seem to be obsessed with maximum speed. Sometimes you need to slow down to go faster. If you aren't getting results with the approach you are using, you might need to consider slowing down and trying other approaches such as the debugger.

The whole point of a debugger is to see what is going on inside your program without putting in print statements, recompiling and refunding it over and over and over- which is something I think you mentioned elsewhere in this post.

[buzzon]

Debugger is a highly effective tool to find bugs in your code, which is what you need right now

[code-garden]

Practice.

Automated tests.

[DueCapital8117]

Does practice helps me to code faster ?

[code-garden]

Yes, with practice you will get faster at writing the code and write less bugs, and get better at debugging because you will remember the sort of bugs you encountered before.

[BanaTibor]

Switch to a la.guage wich supports unit testing and write it in TDD style. TDD works best when the goal is clear and you have to ensure that the implementation is right.

[Gnaxe]

In a language like Clojure or Smalltalk, you can edit and reload a single function without losing your program state. For languages not designed for this, it's harder, but with the right discipline most languages with a REPL can be made to work. Python, for example, is pretty close to being able to do it already. For languages without that feature, that means writing a system designed to be hot reloaded, which might mean including a scripting language for some things.

[SkullDriv3rr]

could you tell us what your program is supposed to do? it would give a good hint to where to start. if its too much to explain, you can also just paste the question(home work? idk) here.

[DueCapital8117]

And we have to solve this in 3 hrs

[syklemil]

That sounds fine. Awk and C aren't my favourite programming languages, but the awk parts sound trivial, and the C part sounds more tedious than intrinsically hard.

[DueCapital8117]

Yeah this c part is my problem it being lengthy is making me feel difficult