[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 May 2015 17:14:32 +0300
From: Shinnok <admin@...nnok.com>
To: john-dev@...ts.openwall.com
Subject: Re: [Johnny] TODO and comments in code
> On May 8, 2015, at 3:57 PM, Mathieu Laprise <mathlaprise@...il.com> wrote:
>
> On Fri, May 8, 2015 at 8:40 AM, Mathieu Laprise <mathlaprise@...il.com <mailto:mathlaprise@...il.com>> wrote:
> A lot of the TODOs are not really TODOs, they are comments or questions. Only a few like the settings are show-stoppers. But in general, I don't think we're gonna gain a lot results feature-wise, quality-wise and design-wise rewriting the 159 TO DOS and it might requires a lot of work of coding + testing that we didn't break something. But they are cool notes of development, if we ever encounter bugs, some questions give possibilities about what could be the cause. A lot could be qualified as comments/notes instead of TODOS.
>
> Also, a lot are saying "I don't know if this is the best way of doing XXX, you can rewrite it if you want". I'll think for a few minutes about each TODO and ask myself 1)"It's not PERFECT, but is it good ? " 2) "What are the benefits of doing it now that it's already done and working?". If there are real benefits, I'll do it. If no, I won't and save time to work on new features. Do you agree with this methodology ?
>
> So I propose to do the important ones only and Windows support until you figure out 1.5.1 requirements. I guess it won't take you a week to figure 1.5.1 requirements out, so we'll be okay.
>
> One thing I forgot to say is that Aleksey did a great job commenting all the code, it's pretty easy to find what you're looking for. It's a really good thing because since MainWindow class has 90% of the code of Johnny (hopes it'll improve someday),it's harder to find what you're interested in. I use control + find often but with Aleksey's commented code it's a lot easier to figure things out. Nice work.
You are free to keep whatever you think is useful to you. I personally don't use comments that are not of either type:
1. Explaining a code intricacy, idiosyncrasy, pitfall or unorthodox usage that absolutely can't be avoided; most can and should be though
2. Explaining an algorithm on the spot
Everything else is either bug tracker stuff, documentation or to be done away with. This doesn't apply to API documentation of course, that's a different game.
If you want, you can use the Github issue tracker. Actually I think we really should use it in absence of anything else.
I've updated version 1.4 Roadmap tasks to include the new stuff and moved the tooltips subtask to 1.9.
Shinnok
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
