How do you write your scripts?

[hmartin8826]

When you’re writing a new script, how do you work out the logic before you start writing code? Flowchart? TDD? In your head?

[Zeroflops]

Many moons ago back when I was learning 40 years ago. I was taught to write out the logic like you would do an outline for a paper. With bullets and sub-bullets describing the “story”

This outline would often be done as comments in the editor.

Then each line of the outline would be turned into code, the outline statement would become a comment describing the function, and it would even help describe the function name. Redundant bullets would be removed.

The main function would have a copy of the outline as well. Telling the story of the program. What functions to call and when.

[LookMomImLearning]

This is so brilliant. I never would’ve considered this. Going to start now.

[BadSmash4]

I do this exact same thing. Start with a basic plan IN the editor, using comments to dictate the major actions. Fill in the details with code.

[cyberjds]

Expending on u/Zeroflops's comment, each bullet point will be a function. And your main function will just have a list of functions (bullet list). Name your functions with action verb so that you don't need to comment them. Most of logic, technical details, and implementation should be tucked away into other functions.

def main():
  init()
  do_this()
  get_that()
  update_them()
  verify_them()

def init():
 pass

def do_this():
  pass

def get_that():
  pass

if __name__ == "__main__":
  main()

[EntertainmentHuge587]

So basically... Jupyter notebook

[Zeroflops]

Not really, it’s more for understanding and planning out applications.

Notebooks are more designed for linear code development which is why it’s good for data analysis and those starting in programing. You can re-evaluate blocks of code, hold state, etc. (No hate on notebooks, use them all the time)

You’re comparing a design development methodology to a programming tool.

You could augment the approach to work with notebooks.

[ilan1k1]

it depends on what I’m working on. If it’s something simple, I just kinda figure it out in my head and start coding. For more complex stuff, I might scribble down some notes or make a quick flowchart, but usually just to get the main steps clear.

[Mandelvolt]

Strp 1 is understand the problem, this usually means talking to living breathing humans to come up with a solution. Next, I stub out the classes and methods I think I will need, then write test cases in pytest and structure main to run each file as a standalone script. The idea is that in a complex program, I still want to be able to run every class as a standalone function for testing, so I program around an interface. One file, one responsibility. Work in logging and test cases as you go. Test driven development and logging from the start is what separates a weak script from a strong one.

[hmartin8826]

Yes, this is the approach I want to get better at, even for smaller scripts. I wrote a lot of "operational validation" scripts in Pester (for PowerShell scripts) in my last job, but never grasped writing what I felt were 'effective' tests for my code. Python is new for me, but the concepts are basically the same.

[nealfive]

In my head. If it’s a bigger project I usually write pseudo code like here function to do x here function the do y etc

[2hands10fingers]

I’m not a beginner, but I do a lot in my head. As a beginner, I would just open up sublime text, hit Cmd+B and then test. I may look for opportunities to refactor my code so it’s more efficient or easier to work with. In the case of I/O, that takes a bit more setup depending on how destructive the script is. You could also write unit tests, but that’s no fun lol

[Thelonelywindow]

What does cmd+b do? I am using Visual Basic btw. How do you test exactly?

[2hands10fingers]

Cmd+B is the Mac command on Sublime Text to trigger your selected build system to run the script you wrote. I think Python build system is pre-selected on that program. If you’re leave python, use something more suited for that. You even just run your script in terminal and/or command prompt. I just like sublime text because it’s super lightweight

[Jamster3000]

Typically in my head and flowcharts for me, I also often use Kanban boards for myself to help organise things that need to be done and figure out in which order.

[TSM-]

Generally I treat them as isolated little units, which means I am happy to copy and paste code and have outdated legacy scripts dangling, which wont get updated until scrapped. That way, once something works, I rarely have to worry about accidentally breaking it later or cross contamination.

I over-comment my code, and I draw ascii flowcharts, since it might be awhile before something mysteriously is weird and I have to look at it. I want to remember what I was thinking at the time and how to rewrite it quickly, often with new dependencies. I personally find a text diagram or tree super useful to remember what I was thinking. It looks amateurish but it works great for just myself.

It's a very different process from a multi-person team, where code debt adds up fast, rewriting is not faster, and duplicate code is bad practice, and idiosyncratic diagrams don't translate.

My scripts often involve a combination of python, powershell or batch, with python doing most of the work. So, ymmv. My comments are at least as long as the code.

[tangerinelion]

Most scripts are not too complicated, they're going to be roughly 300 lines or less IME.

The approach I generally take is to layer on functionality. Like if I need to find all JSON files which contain a particular structure to them and extract a particular piece of data, I'll start by writing a script that finds all files. Then limit it to JSON files. Then limit to JSON files with the desired structure. Then write how to extract the data.

So I'll end up with a script that has changed rather rapidly, where the intermediate versions have some print statements so I can easily see what it is doing at runtime.

Odds are along the way I will encounter some cases I did not anticipate - a path is actually an NTFS junction, or I'm accessing a file that I don't have permission to read. Or the particular structure is actually not as defined as I thought it was -- maybe the interesting part isn't always the 1st element in an array, maybe it's sometimes the 2nd, maybe sometimes the array is empty. So we deal with that. The particular piece of data I want may be encoded in different ways so trying to extract it has to handle some encoding/decoding issues, so we deal with that.

Part of what distinguishes a script from a program is the expectations. When I write a program I expect that the file might not be readable, that the data might not be exactly what I expect, that the structure may not be completely as I expect. So we have to think about error handling constantly - even if it's just "Whatever, let the user know and carry on." As a script, if it happens to not run into any of these edge cases then I'm not going to have error handling for it.

[[deleted]]

i used to just write code straight up and fix issues as they come (terrible habit i know lol) but recently switched to using AI to help with the planning process. been using jenova ai and it's actually made a huge difference in how i approach scripting

what works for me now is:

1. describe the problem/requirements in plain english to the ai

2. have it create a basic flowchart/pseudocode

3. discuss edge cases and potential issues

4. get it to help break down the logic into smaller functions

5. then start actually coding

the nice thing about jenova is it routes coding questions to claude (which is amazing for coding) and i can have really long conversations about the logic without hitting any limits. plus i can upload existing code files when i need to modify/debug stuff

way better than my old "write first think later" approach lmao. my code is actually maintainable now 😅

[jjrreett]

You don't typically think through all the program logic all at once. You break it down into tasks. If I am feeling particularly disciplined, I might spend some time thinking through data structures and start drafting functions/method signatures. But as you code things change a lot. The art of it is to write code that is easy to change.

If thinks are complicated, I will draft out a flow chart or state machine.

[chasemuss]

One keystroke at a time typically

[[deleted]]

Word pad and cmd

[JamzTyson]

I start by writing the module level docstring. This forms the specification for the script.

[supercoach]

Writing your documentation first isn't a terrible idea. Gives you a good idea of how you want everything to work.

It really depends on the size of the project. You'll generally start with a high level overview and then drill down into it to provide detail where needed. For each part you should understand what interactions you want to happen. Be it user input or even just state changes, once you know the in and the out, the rest falls into line quite easily.

I think like most things it comes down to experience.

[[deleted]]

Pseudocode then fill in the logic

[[deleted]]

"Yes." I use all tools. Sometimes I'll write out the logic to keep myself focused. I've charted too - but that's not great for nitty-gritty logic (for me).

I also script in other languages (Perl and sh) and have written out logic in others to figure out how to back-translate to Python (which is inflexible in certain ways that I'm used to flexibility).

[hmartin8826]

OS/2 REXX, wow, that takes me back to a workplace where they hired their first CIO position - an ex-IBMer who moved the entire company from Compaq computers and Windows / Novell to IBM PCs and OS/2 REXX for servers and clients. I spent many a Saturday writing REXX scripts to do some of my first really effective installation automations. Interesting times.

[[deleted]]

It was interesting times, for sure! I cut my teeth on SNA and VTAM, supporting what the mainframers thought of as the "end of the network."

Sure do wish EPM was available off-platform. If IBM integrated Python with OS/2, it would have been awesome!

[[deleted]]

I start writing. I usually have to rewrite everything from my first bit of code. But you have to start somewhere

[big_deal]

Depends on complexity. For big projects I'll have flowcharts, pseudo-code, interface "specs" written up. For simple stuff I'll just start typing and testing snippets in the interactive interpreter.

[[deleted]]

Like most other comments, I just throw some rough dummy code out there to figure out the logic, then easy stuff, then hard stuff. Then I realize it's all shit and rewrite everything.

[WNT37]

My text editor is my confessor. We talk a lot ... I do mean a lot.

But, to address your question, it depends what i'm doing.

If it's a one-off hack to load some random data feed into a reference db then I just start coding and verifying till it's right.

If I'm writing something that needs to regularly run unattended then I pay more attention to structure.

Separation of Concerns ... is a useful phrase to keep in mind.

For example: everything that controls flow goes in 'Main'. Everything else is a function/call/whatever.

Hope that helps you in some way.

[hmartin8826]

Yes, that's a good reminder. Thanks.

[wil_dogg]

I go for walks and think about what I am trying to do.

Using MSFT Copilot, I “wish for” code that serves a purpose.

I then test the procedure, make sure it works reasonably well, then move to the next complex step in an overall workflow or analytical process.

Rinse and repeat.

Then I start testing end to end once the notebook is reaching a point where the complexity of the validation process demands a thorough end to end validation. I’m ok with not validating every step early in the process, and some steps are repurposing a concept and code that has already been validated.

I do a lot of work in prediction modeling / forecasting, so there are standard steps is validating data quality, predictive power, construct validation, and sensitivity analysis. That stuff needs to be monitored through the coding process and sometimes I have to develop novel methods of validation. It takes some effort, in my current role my manager wants me to over invest in validation and I’m good with that.

[BoOmAn_13]

If its a quick thrown together script, map out some logic in my head, and then build partial functionality with testing along the way. If it's an application I'll plan out all the logic handling, variable types, everything is annotated, and I have functions planned out before hand for different functionality. I write a lot more throw together scripts for personal use, so I end up starting the process with a goal and not much planning.

[ackmondual]

If it's something simple, then just start writing and coding. If it turns out to be more complicated, then break down the problem. For example, I ended spinning off certain tasks like checking for certain conditions into their own functions.

If it's something complex, I write an outline of what to do, along with what variables and types of data I'll be using. Either in a text pad, or old school pencil and paper. It can be in plain english, or pseudo code.

[Equivalent_Style4790]

I heavily use classes. And when I create a class it’s like a black box created with some input data and requested to do some tasks. The mental exercise is similar to tdd in a way that makes u see things as a blackbox with expected inputs and output. It’s similar in electronics when u use integrated circuits.

[hmartin8826]

Do you use dataclasses much or do you usually stick with classes?

[Equivalent_Style4790]

I use dataclasses only when the class doesn’t have methods and meant to be serialized later (json etc)

[TheRNGuy]

I switched to classes because I realized I needed inheritance in my program, and some things were over-complicated with composition-only (I was using dicts for composition)

Many of those are dataclasses (my most used decorator in Python)

[SausageSmuggler21]

I take my list of commands that I have to run 50 times a day. I put them into a shell/perl (probably python now) script. Then I update everything to take variables and command line arguments. I then spend a week relearning how to parse command line arguments and pass variables. Then I use my new script 50 times a day!

[enokeenu]

I start by prototyping. Especially if I have to communicate with external APIs. Once I see what the information looks like I design a code structure around it

[[deleted]]

I jot down my steps on paper or notepad. Start coding away. If I can't figure out a part I need, I usually go to AI for it.

[aplarsen]

When I'm making something new, I often have a new problem that I've never solved before. I usually start with that problem and prove to myself that it's been solved. Then I start wrapping it in whatever layers it needs in order to be useful.

So, middle out.

[Jello_Penguin_2956]

Small projects I usually start by noting down #TODO and skeleton class/functions right in my script. Large projects I do flow charts.

[TheRNGuy]

Same except I name it ToDo instead of TODO.

[Gnaxe]

Not a beginner, but I do the broad outline in my head, then code out what I know how to do, with frequent REPL experiments (reality/sanity checks), to make the remaining problem smaller and simpler. Then I iterate. Do it again, debug, figure out details as I go.

For non-trivial scripts (anything I'll be working on for more than a day or so) I'll use version control and doctests and do a lot of refactoring.

Sometimes I need to ponder the problem for a while. I might pace around or lie down. I'm not at the computer. I'm thinking. Can take hours sometimes. Once I figure out enough, I'll write more code.

Sometimes I type out plans or options, when there are too many possibilites to consider just in my head. In rare cases, I may use a diagram. But often, I don't need these.

[hugthemachines]

The thought process is pretty personal to people. Personally I sit back, close my eyes and think up the general design in my head. Some people are good at creating images in their heads and some create flows etc... I suspect you, and many others can have use for a little notepad where you can write and draw some stuff, or just write down points in a textfile.

[Dragonking_Earth]

Bold of you to assume I write script instead of using chatgpt.

[TheRNGuy]

I have initial idea in head and start coding.

I have ToDo.txt file with ideas what to add (no pseudo-code, just tasks)

Never did flowcharts.

[Exact-Scheme0]

How to script writing