What is your programming style?

Question

I mean, how is your process in program whatever thing that you think.

For example, my process is identify the problem to solve, and then I go stablishing the variables, and despiece the steps to take, sometimes I have a sketch of it, then those small functions I go piling below the code, and at finish, I compose the solution.

Some times I make some variation in how I write the code.

😀

Share your style below, or some styles that have you seen and you would like to implement it. 👍

Answer 1

• The Good Programmer One:

1) I see the problem
2) I try to solve it in many different ways, if the problem is very hard to solve i like to isolate all the code and keep just the portion of code that contains the bug, i make use of platforms like JSfiddle and Codepen to test the code.
3) Now that i have the solution, i write the fixed code as it is
4) Time to refactor, i try to implement the cleaner solution to solve the same problem.
3) I feel good

• The Lazy One:

1) I see the problem
2) StackOverflow
3) Problem solved

Generally i mix both of them to solve the problem, i'm trying to implement the following approach:

• The Docs One:

1) I see the problem
2) I try to solve it by using the official docs
3) I feel good

Answer 2

1. Think what to do
2. Sometimes, I write algorithm on paper
3. Create code
4. Compile
5. Search error

Answer 3

My style is what I like to call "Movie Magic." I just tell people around me to "Wait one second... I got an idea!" and then I violently bash my hands into my keyboard for 10 seconds before announcing, "Okay! I did it!"

Seriously though, first I consider whatever the task/project/problem is. Figure out exactly what the specifications are for it; if you're doing this for someone else, ask them and ask them again if needed. Create a flowchart to map out the flow of the program; it's kinda like a blueprint to help you program it and helps you think of aspects you may not consider prior. Then I program in chunks and test the chunks prior to moving on to the next chunk.

Answer 4

1. Analyze the given problem.
2. Prepare pseudo code(algorithm).
3. Prepare code(program).
4.Then compile.
5.If any errors are there, then try to debug.
6.After removal of all the errors and then execute.
7.Check whether it is satisfying all the test cases or not.
8.If satisfies all the test cases, then it is Okay,Otherwise try to change the logic and then execute.

I try to execute the program without any errors by following the above 8 steps.

Between Congratulations for post of the day👏👏👏

Answer 5

I'm a beginner...

>first I observe the problem
>search for logic to find the solution
>after finding the logic, I write a code on a paper according to the logic
>analyze it once with some examples (inputs)
>make some corrections if necessary
>write that code on SoloLearn
>execute the code for different inputs
>correct the errors if any.,
>again execute the code for different inputs to get the correct output
>and finally post the code!!!

Answer 6

Side note: I am a rather experienced programmer.

It depends a lot on the complexity of the problem. If it's simple I usually just start typing in the required language, then try to let the code speak for itself as much as possible.

If the problem is more complex I usually start with a design, i.e. breaking up the problem in smaller pieces that can more easily be solved. Then continue breaking down until the pieces are simple enough to solve. Whenever I want to add something to the code I start by going back to the design and ask myself: who'se responsibility is this, what is the desired outcome of what I am adding, how will it be used, stuff like that.

In the mentioned design phase I usually take some time to really try and understand the problem, I do that by discussing the design with the one who wanted the code in the first place and then discussing the design with other experienced programmers.

Answer 7

1---understand the problem
2---make some sketch
3---relate it with some of familiar algorithm
4---start working on it
5---stuck take some break start again
6---stuck have some coffee start again
7---stuck check documentation
8---stuck start complaining
9---finally stack overflow my saver
10---time to start solving the problem in professional, less complex, fast, documented and clear way
11---refactor my code
12---check my code as if I am reviewing someone's code
13---call it a day ,feel great , have some fun and go to step 1 again

general algorithm for programming style

1..start
2...code
3...does it work
no
mess around
repeat step 3
yes
repeat step 2

Answer 8

I m still finding it out...😂😂😂
-->think for any idea , despite of knowing that I m not going to get any idea...
-->Search for any challenge which is not way out of league... 🤣🤣🤣
-->Get idea from other's code... then code it down
most probably I try to use a language which is not used by other....
-->Mostly I convert other's code in different language... from what they have used..✌️👍😎
Congratulations for post of the day...

Answer 9

1sit down rehearse the problem and thing what to do 2 if the things is very familiar to me start write algorithm for specific task if not collect resource that will help to solve the problem
3compile the code try to see the output
4if it result a error try to debug as far as I know

Answer 10

Stupid, chaotic and ridiculous style of coding with all possible violations😂

Answer 11

1: make the code
2: revise the code
3: if there are problems try to fix it
4: if I can’t figure it out, ask someone on sololearn.

Answer 12

1. Visualization:
- how it should work (requirements)
- solutions to solve the problems
(helps: drawing on paper, internet)
2. Implementation
- if something is unclear - back to 1st step
3. Tests and Debugging
- if it doesn't meets all requirements - back to 1

Answer 13

There will be no styles in the future. We all will in virtual mental matrix and will have only one true mental and not verbal language😀

Answer 14

My Style In Pen Testing Or Programming:
Get Some Analysis My Target/My Idea
Understand What I Will Do And What Are The Risks And Possible Bugs🔎
Write My Scripts, Test Them And Debug Them >>>💻
Fix Any Bug 📲❎
Make A Highlights For Terminal ✨
Finally Exploit My Target🎯/Install My Setup And Use It 💿

Answer 15

I am a dynamic programmer I.e whenever i see the problem i start breaking it to smaller parts and wrap them single functions for each broken problem and then i move to the main problem and solve it in a single line by using wrapped function together

for eg:
Suppose the problem is to find the sum of factorial of each number so i will first break it and create a function that will find the factorial of the returned number and then I will create a function that will break the given number and by using both the function i will get the result easily rather then to do all work in one function

hope you enjoyed today's lesson 😂
Thank you

Answer 16

Often end up writing at least some pseudo-code on paper before even trying to write a single line on a machine. Sometimes, at least if the project is small, I'll write the whole thing out on dead tree before beginning to implement it. Being able to see a version of the code, even if it's not exactly what I'm working on, helps me notice some issues that aren't immediately obvious in the "design" phase.

There's other ways too of course, this is just what usually works best (for me) although of course some other styles work better at different times.

Answer 17

I'm still struggling b/w all those functions and strings.
how could there be any fixed rule to code

Answer 18

My style is hoping for the best result doing less, but efficiently 🤔

Answer 19

i think in feature my programm style is 3d ☺☺

Answer 20

I am dreaming big for programming but i am always lazy when i started studying programming languages and leave in half..
maybe 70% have same problem....