by sondr3 on 2/27/24, 11:47 AM with 41 comments
by Someone1234 on 2/27/24, 4:22 PM
For example:
// How: This filters records by MyType of J and if they have children
// Why: We want Jobs (J) when those Jobs have Children. Otherwise, we'll get JobGroups or Jobs without any Children we need to process below.
.Where(T => T.MyType == "J" && T.Child.Count() > 0);
WHY are, by their very nature, business rules or explaining a thought process. If the original developer of the code moves on or is unavailable, that information can sometimes not be found elsewhere.by timetraveller26 on 2/27/24, 4:01 PM
And funnily enough, bad advertisement. How could a startup that focuses on code think that making a PR with 3,158 changed files is acceptable?
by preommr on 2/27/24, 4:31 PM
I just experimented a little bit, and telling chatgpt to assume a self-documenting approach and skipping comments whenever possible, gets a pretty minimalist output. Add on asking about what non-obvious aspects might be noteworthy based on other projects, and I bet chatgpt would be able to find a list of things to look for, see if it's applicable, and then rewrite in the appropriate format. Like if the function is about sorting, it could figure out that knowing if it's stable is an important marker, and figure that out. Something like that could be useful.
by lelandfe on 2/27/24, 3:51 PM
by mateusfreira on 2/27/24, 3:43 PM
by ptx on 2/27/24, 4:26 PM
by shadowgovt on 2/27/24, 3:51 PM
One is that (glancing through the comments) they're actually significantly more thorough than what is already there and they're at the level of thoroughness that a new user may actually want. Phil Webb is quite right; this is the level of detail someone new to the codebase could use, and if you could generate it dynamically on the fly as a "Help me understand what I'm looking at" tool that'd be really nice-to-have.
Second: I've definitely worked at places so tight-ass about code documentation that they do want "makeAppleRed(): Makes the apple red." Mostly because they're using doc engines that do a bad job of letting you know a function exists at all if it isn't documented. I have no doubt Codemaker is going to make its money on those places.
by cj on 2/27/24, 3:58 PM
by TrianguloY on 2/27/24, 4:45 PM
Note: I'm not talking about things that you know just by looking at the method itself, but things that are obvious when reading the code of the method only.
/** This will return the data */
Data getData() {...}
This is useless, But /** This will return true iff it's not empty */
boolean isValid() {return !empty();}
This is useful. This is what a good documentation should provide, and having documentation in the code itself (that you can later extract to an html page or other) is way better than having it on a separate platform that you need to remember to update.Edit: remember that this is library that other people will use, it's not an internal tool that only your team knows about.