|
Truly this is a week of miracles: today someone on the internet was swayed by logic  and yesterday I saw a BMW driver use his indicators*! 
These things never happen: what in in store for tomorrow? 
* No, really. And correctly too. I was so surprised I assumed I was still asleep and dreaming.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'm with Griff on this one. Being able to set break points and see how information is passed in an IDE helped me understand coding that much more.
|
|
|
|
|
Yeah, I disagree as well. I eschewed IDEs for most of my career favoring just plain vi--even on Windows--but since discovering Visual Studio Code, that all changed. With its VIM plugin, I can have the best of both worlds--a vi-like UI with all the VSC bells and whistles.
For a complete newbie, an IDE can be a help and a hindrance. The sheer volume of options, settings, and plugins cam be a challenge and can quickly overwhelm a first timer.
I'm like OP. My career is nearing a close. My first coding experience was also in 1986. The language was Exec2, and the hardware was an IBM System 370 mainframe. That was a different time. There were few tools available (Anyone here remember troff?), few language options, and no Internet to use for research. Now, starting out can be both easier and harder. Easier because there are so many more options to choose from and harder also because there are so many options to choose from. At least there are many great sources of information these days, but this is even problematic because misinformation is just as common as the good stuff.
Of course Kimmie needs to tell us a little bit more about what kind of programming they want to do. If unknown, my tip is to start with defining that.
Cheers,
Russ
|
|
|
|
|
I remember TRS-80 BASIC. TROFF and TRON to trace program execution. Now I use print statements to include variable values and don't output line numbers except before and after conditional branching.
The old days weww so much simpler, but we didn't have enough RAM to work out bugs easily.
|
|
|
|
|
LOLs The troff (pronounced T-Roff) I was referring to is the old typesetter symbolic language processor for formatting documents.
|
|
|
|
|
I have clue on coding but I like try if you don't want me here I will go. I do not have any experience in this. Tell me where can go to learn and don't have to both anyone thank you Kimberly Hall
|
|
|
|
|
It is worth having a look at the way the Git project writes it's Commit messages and it's documentation in terms of shifting from a subjective style of writing about what happened, to an objective imperative style. After a while of following along you start to see how you can stop apologising for what happened, and instead assert what is happening. We are taught (English 101) to write long waffle sentences, rather than short, concise and informative ones that we really need here.
git/Documentation/SubmittingPatches at master · git/git · GitHub[^] The "Describe your changes well" section is a good start.
|
|
|
|
|
honey the codewitch wrote: Just writing out how to use it uncovers areas for improvement.
I also shored up some function names that were out of step with my conventions.
I've had that happen myself. I'll notice little inconsistencies in how things are implemented, usually the sort of thing you refactor after some experience with the code. If a class is sufficiently complex, it's as if it forms a grammar. Making sure the right things are "nouns" and "verbs" and are named appropriately is sometimes easier to see when you're talking/writing about the code rather than creating the code itself.
Software Zen: delete this;
|
|
|
|
|
I don't document the code, so much as document the application/utility -- such as how to use it, how to specify command-line parameters or write a script.
But, yes, that often leads to reviewing the code and making improvements.
In some cases, I begin with a document of the list of features I want and such.
|
|
|
|
|
I look at my app, and if something needs documenting, I figure it's probably too hard and should be rewritten. My documentation mostly consists of (control) tooltips.
I used to create elaborate help files (using Help Workshop, etc) until someone decided to condense my help into a "guide" ... sort of like ketchup on one's filet mignon.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Libraries like my graphics library pretty much demand documentation if anyone is going to use them.
There are simply too many features to expect someone to find their way around by themselves.
For example, my graphics lib supports 3 different types of fonts, each with different capabilities.
I mean, The STL demands documentation simply for the breadth of it, never mind the complexity.
I try to keep my code as simple to use as possible, and no simpler. Even in those cases, sometimes a project just demands documentation.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
API's are different. I contrast "user" documentation and "system" documentation. And I use Visio for both. And Excel. And Word. Creating "internets".
"Users" bother with none of the above. I create "user interfaces".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: My documentation mostly consists of (control) tooltips.
Ooh, I really hate apps that assume that I will have the same mental model as the developer, especially when I don't  . The expectations can easily lead into traps one can't get out of, and worse, ditching the app or tool.
That said, it is really frustrating trying to explain something when you haven't established common ground from the start (the "your breakfast may be different from mine" problem). So at least having a purpose, concepts and usage approach documented will give users a clue as to where the code is going, especially if the app is 'special' (i.e. different to regular expectation).
|
|
|
|
|
I never release an app I wouldn't use myself. I understand the concept of "flow". At the end of any project, I know more about the users' problem domain, than the user. Preaching to the choir.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I view documentation as absolutely essential and just part of doing a good job. If class and function names are genuinely sufficient, then that's fine, but if you try and ask yourself all the questions that a new user of your code might ask, frequently there's plenty to document for clarity. I'm quite lucky in that I have a lousy memory, so when I return to my code later, I may not be that far from a new user of it myself! I find myself thankful to myself for getting the necessary details explained and documented clearly! I think if a user of your code has to read any of the code in your function bodies, your documentation is insufficient.
I also think it's also valuable if you can to spend some time writing code that consumes your code - essentially walking in somebody elses shoes. It can show you how easy or otherwise it is to work with, and can reveal opportunities to improve the design, or perhaps suggest function overloads you can provide simpler versions of to reduce any pain. If there's anything cumbersome or unintuitive about your code, you'll hopefully encounter it and be able to rectify it.
|
|
|
|
|
I started my embedded coding career in 1978. I was writing code for the Motorola 6800 by the op codes (we didn't have a 6800 assembler yet). Documentation was a definite requirement. I pretty much just automatically document my code since then. First, I know it's not necessarily me that's going to be taking care of the code, so I want it to be easy to understand my thought process.
|
|
|
|
|
Attack the parts list singer? (7)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
just to get it outside Wales...
BOM parts list (bill of materials)
BARD singer / poet
attack - def.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
And you are up tomorrow! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I thought up a good one over the weekend, and I can actually remember it! 
The timing tomorrow may be a bit off. I *should* be at my destination by then, but given it's 500 miles away and involves several modes of transport to get there....
Prompted by last week's comment from @megaadam, maybe we "regulars" should consider some kind of time constraint on ourselves.
For example, @OriginalGriff and @petepjksolutionscom should not be able to answer for one hour; I'd happily take a half hour hit, and maybe the immediately preceding setter should too. What say, peoples? Anyone got a better idea for spreading the joy?
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I'm fine with that.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
We ( me and OG ) did do that for a while but it didn't make much difference
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Given how rare it is for me (and maybe others) to solve the CCC, I don't think it would make a lot of difference.
|
|
|
|
|
agree.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
Ok with me to 
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
