5 ms·

$yourFavoriteLanguage already has a mechanism for chunking. They're called functions. (Okay, so if $yourFavoriteLanguage is CSS, maybe not.)

• Retra 11y ago
  Those functions don't always align with the problem model, and they often have a cost associated with their use.
• noxToken 11y ago
  My only thing is that there are times where relatively unknown structures (to the team anyway) can be used to achieve a task. Inline comments can alleviated some time wasted doing external lookup when trying to debug something in the function: ExecutorService exec = Executors.newSingleThreadExecutor(); //instantiate thread manager Future<?> future = exec.submit(serviceTimer); //queue thread for async execution exec.shutdown(); //execute queued thread and deny additional requests for execution All of these inliners are explained in the docs, but sometimes it gives a warm and fuzzy when the author explicitly states what is happening with a comment.
  • untog 11y ago
    All three of those are just bad function names, though. Executors.instantiateThreadManager() exec.queueForAsyncExecution() exec.executeQueued() would all be a far better solution than putting an inline comment on everything.
    • noxToken 11y ago
      While I agree, those are all built-in functions. I suppose that's why there's the doc-on-highlight feature. I'd need to wrap them if I wanted just to rename them.
    • jdbernard 11y ago
      No, the original function names are better than your replacements, because they accurately describe what the functions will actually do instead of assuming they know what the user wants. Your names imply non-trivial differences in the way the functions work. These are library functions, so their names must be carefully chosen to imply only what the contract of the actual method supports. In particular: Executors.instantiateThreadManager() You lose information about the thread count (single thread). Also, a nitpick I know, but in Java new means instantiate, so just say new and save typing. Also, an executor is not guaranteed to be a thread manager in any meaningful sense. It is only guaranteed to be an Executor. exec.queueForAsyncExecution() This may not actually be async. 9/10 it is, but the interface does not guarantee async, just a de-coupling from queuing and execution. exec.executeQueued() This misses the fact that calling shutdown will deny future tasks from being queued after it is called. This is actually a great example of why function names are not a sufficient replacement for appropriate comments.