Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 May 2015 17:26:45 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re: [Johnny] TODO and comments in code

On Wed, May 06, 2015 at 04:52:01PM +0300, Shinnok wrote:
> > On Apr 28, 2015, at 10:32 AM, Shinnok <admin@...nnok.com> wrote:
> > 
> > Hey Aleksey,
> > 
> > The code in the current state has 179 TODOs and NOTES as comments. That is too much for the amount of code Johnny has at this point. I'd like to get rid of most of them so that we can proceed with coding without being distracted by all of that.
> > I'm not sure what is the best way of doing this. I can think of these following two approaches:
> > 
> > 1. I could go over them and obliterate anything that doesn't make sense to me.
> > 2. You could go over them, assuming that you remember enough, and in the same fashion obliterate anything that doesn't make sense currently or was part of your initial effort and understanding.
> > 
> > Anything that is a future TODO and can't be (re)written on the spot with a single line should probably be converted to a task.
> > 
> > I'd be a bit inclined to say that the best approach would be the second one but if you can't do that in the near future that is fine.
> > 
> 
> 
> Mathieu, do you think you could take on this until we decide what's to be done for task 1.5.1 ? I'm confident you can do it without much trouble.
> 
> You can make a branch and work on that. Any difficult task/fix/question you come about you can add it to a list then share it here when you're done. Or Github issues, whichever you find more comfortable.
> 
> I think this would be a good exercise in breadth over Johnny's code. I'm also a bit in a need to buy more time in order to refine the current release plan and tasks.

I am sorry for not taking it so far.

Most probably all TODOs describe things that have low importance.

They document workarounds, compromises that I was not satisfied about
and things I was not sure about (it may be interesting to test corner
cases around such TODOs). They may be helpful when you get into
trouble and/or are going to implement something new related to that
code.

NOTEs are not actionable at all: they describe peculiar moments
(including compromises I like) and some of them are written thinking
about possible future changes.

Though some of TODOs may reflect previous view on some features to
implement later. Such TODOs may be removed or converted into separate
tasks on the roadmap.

I think TODOs should not be distracting because they are very low
priority tasks. I think it would be better to spend time implementing
and reimplementing 1.5.1 than working on TODOs in code.

I'll take a look on the todos today.

Thanks!

-- 
Regards,
Aleksey Cherepanov

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.