开发者

should I write more descriptive function names or add comments?

开发者 https://www.devze.com 2023-02-15 08:27 出处:网络
This is a language agnostic question, but I\'m wandering what people prefer in terms of readability and maintainability... My hypothetical开发者_如何学Python situation is that I\'m writing a function

This is a language agnostic question, but I'm wandering what people prefer in terms of readability and maintainability... My hypothetical开发者_如何学Python situation is that I'm writing a function which given a sequence will return a copy with all duplicate element removed and the order reversed.

/*
*This is an extremely well written function to return a sequence containing 
*all the unique elements of OriginalSequence with their order reversed
*/    
ReturnSequence SequenceFunction(OriginalSequence)
{...}

OR

UniqueAndReversedSequence MakeSequenceUniqueAndReversed(OriginalSequence)
{....}

The above is supposed to be a lucid example of using comments in the first instance or using very verbose function names in the second to describe the actions of the function.

Cheers,

Richard


I prefer the verbose function name as it make the call-site more readable. Of course, some function names (like your example) can get really long.

Perhaps a better name for your example function would be ReverseAndDedupe. Uh oh, now it is a little more clear that we have a function with two responsibilities*. Perhaps it would be even better to split this out into two functions: Reverse and Dedupe.

Now the call-site becomes even more readable:

Reverse(Dedupe(someSequence))

*Note: My rule of thumb is that any function that contains "and" in the name has too many responsibilities and needs to be split up in to separate functions.


Personally I prefer the second way - it's easy to see from the function name what it does - and because the code inside the function is well written anyway it'll be easy to work out exactly what happens inside it.

The problem I find with comments is they very quickly go out of date - there's no compile time check to ensure your comment is correct!

Also, you don't get access to the comment in the places where the function is actually called.

Very much a subjective question though!


Ideally you would do a combination of the two. Try to keep your method names concise but descriptive enough to get a good idea of what it's going to do. If there is any possibility of lack of clarity in the method name, you should have comments to assist the reader in the logic.


Even with descriptive names you should still be concise. I think what you have in the example is overkill. I would have written

UniqueSequence Reverse(Sequence)


I comment where there's an explanation in order that a descriptive name cannot adequately convey. If there's a peculiarity with a library that forced me to do something that appears non-standard or value in dropping a comment inline, I'll do that but otherwise I rely upon well-named methods and don't comment things a lot - except while I'm writing the code, and those are for myself. They get removed when it is done, typically.

Generally speaking, function header comments are just more lines to maintain and require the reader to look at both the comment and the code and then decide which is correct if they aren't in correspondence. Obviously the truth is always in the code. The comment may say X but comments don't compile to machine code (typically) so...

Comment when necessary and make a habit of naming things well. That's what I do.


I'd probably do one of these:

  • Call it ReverseAndDedupe (or DedupeAndReverse, depending which one it is -- I'd expect Dedupe alone to keep the first occurrence and discard later ones, so the two operations do not commute). All functions make some postcondition true, so Make can certainly go in order to shorten a too-long name. Functions don't generally need to be named for the types they operate on, and if they are then it should be in a consistent format. So Sequence can probably be removed from your proposed name too, or if it can't then I'd probably call it Sequence_ReverseAndDedupe.

  • Not create this function at all, make sure that callers can either do Reverse(Dedupe(x)) or Dedupe(Reverse(x)), depending which they actually want. It's no more code for them to write, so only an issue of whether there's some cunning optimization that only applies when you do both at once. Avoiding an intermediate copy might qualify there, but the general point is that if you can't name your function concisely, make sure there's a good reason why it's doing so many different things.

  • Call it ReversedAndDeduped if it returns a copy of the original sequence - this is a trick I picked up from Python, where l.sort() sorts the list l in place, and sorted(l) doesn't modify a list l at all.

  • Give it a name specific to the domain it's used in, rather than trying to make it so generic. Why am I deduping and reversing this list? There might be some term of art that means a list in that state, or some function which can only be performed on such a list. So I could call it 'Renuberate' (because a reversed, deduped list is known as a list "in Renuberated form", or 'MakeFrobbable' (because Frobbing requires this format).

I'd also comment it (or much better, document it), to explain what type of deduping it guarantees (if any - perhaps the implementation is left free to remove whichever dupes it likes so long as it gets them all).

I wouldn't comment it "extremely well written", although I might comment "highly optimized" to mean "this code is really hard to work with, but goes like the clappers, please don't touch it without running all the performance tests".

I don't think I'd want to go as far as 5-word function names, although I expect I have in the past.

0

精彩评论

暂无评论...
验证码 换一张
取 消