Code flag to indicate a need to revisit the code / locate unfinished code?

Thomas Sødring Thomas.Sodring at hioa.no
Tue May 30 09:48:13 CEST 2017


Hi,


I don't need to introduce papercut, I just thought it was interesting in relation to your question. I'm a bit wary of annotations, as I see that sometimes they are a lot more than what meets the eye. I'd like to keep the codebase as clean as possible. The last while I've quietly been removing the @Autowired annotation and gone back to more classic Dependency Injection to keep nikita more in line with JavaEE than spring.


I would have thought there was more than 60 TODOs but perhaps that's a good starting point. Some of them are probably in code that can be removed.


I agree, that we continue with TODO and have a go looking at them. I'm bogged down with other stuff at the moment so don't have time to look at it, but when we have a round on fixing stuff that coverity finds, maybe we could start removing TODOs aswell.


Quietly the last while I've also been making sure java files have no warnings. When I'm working a file I Iook at the warnings Idea is telling me and do my best to remove all of them. I'm seeing some warnings for methods that are never called so that's a good place to look for potential bugs.


 - Tom


________________________________
From: nikita-noark-bounces at nuug.no <nikita-noark-bounces at nuug.no> on behalf of Petter Reinholdtsen <pere at hungry.com>
Sent: Tuesday, May 30, 2017 9:29:27 AM
To: nikita-noark at nuug.no
Subject: Re: Code flag to indicate a need to revisit the code / locate unfinished code?

[Thomas Sødring]
> First off, what you are seeing there is from very early on in
> implementation, you'll notice that it's searching by id, not systemID,
> so this is from the time it was unclear in the standard if we should
> use id or systemIDs to retrieve objects. It was also unclear if we
> should also be allowed to search by id. This method can safely be
> deleted.

OK.  But I believe we should start by flagging all such issues in a way
that allow us to count their number, to actually see that the amount is
shrinking, before we start removing the code.

> If you search for TODO: you will probably find what I didn' t get
> around to doing.  There are many, but they are shrinking .

So you have been using TODO as such flag already?  I find 60 lines with
'TODO' in core-*.

> I did consider using the following.
>   https://github.com/Stuie/papercut
> I do like the approach here.

Look useful, but perhaps a bit overkill?

> Perhaps we should try and include papercut, but I am trying to
> introduce finished blocks of code, rather then half blocks.

I am reluctant to introduce more dependencies, espesially those not
already in Debian, as it make it harder to get the API implementation
into Debian and other linux distributions.

What if we stick with TODO for now, and consider transforming them to
the papercut notation when we have a more complete picture?

--
Happy hacking
Petter Reinholdtsen
_______________________________________________
nikita-noark mailing list
nikita-noark at nuug.no
https://lists.nuug.no/mailman/listinfo/nikita-noark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.nuug.no/pipermail/nikita-noark/attachments/20170530/4ddfdbae/attachment-0001.htm 


More information about the nikita-noark mailing list