|
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
|
|
|
|
|
Just did a search for "javascript force to a number", since I was having trouble converting an enum to a number. The third result was to an article titled "The White House Task Force on Worker Organizing and Empowerment: Update on Implementation of Approved Actions". It didn't contain the work 'javascript.' God, Google is starting to really f***ing suck!
I did solve the issue (a syntax error in my calling code), but my eyes still hurt, and I expect they will for a while!!!
 (but no smile - a huge frown!)
|
|
|
|
|
Maybe it was a sponsored link.
|
|
|
|
|
Maybe the word "force" made Google think it as some kind of military force.
|
|
|
|
|
I'm willing to bet the page contained the word javascript somewhere.
might have been "text/javascript" though. 
|
|
|
|
|
Yep. As well as "You have JavaScript disabled. Please enable JavaScript to use this feature." in a class.  Since I haven't disabled Javascript for the site, it didn't affect the view. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
