[Networkit] Code Quality

Christian Staudt christian.staudt at kit.edu
Mon Aug 18 12:52:37 CEST 2014

I basically agree with all of the points. Let me add a few lessons I’ve learned in the course of the project:

- Significant code changes should be subject to peer review. Writing high quality code all on your own is hard. I strongly suggest that all developers submit their updates for review on the email list.
- Not writing (good) test cases saves you a little bit of time, likely at the expense of a lot of someone else’s, who will rely on the correctness of your code.
- Existing code ages and needs to be maintained, especially in a fast moving project like NetworKit. API changes can break existing client code within the project. Those making the API changes cannot always be expected to adapt client code they may not know much about. 
- Sometimes the best code is the code you don’t write. It contains no bugs, does not need to be maintained… First think about what can be done by composition, then think about extension.

Best regards,

christian.staudt at kit.edu
Institute of Theoretical Informatics - Parallel Computing Group 
Building 50.34 Room 034
Karlsruhe Institute of Technology (KIT)

Am 17.08.2014 um 11:55 schrieb Marvin Ritter <marvin.ritter at gmail.com>:

> Dear NetworKit Developers,
> today I noticed some things that we might want to improve in the future:
> 1) Be more careful with changes to core classes (e.g. Graph, readers, ...)
> Example: Someone changed the parameter of Graph.BFSfrom (the handle gets now 2 parameters).
> I think it is fine to change the interface (backwards compatibility just slows down development), but please make sure to minimise the number of changes and think well about them (ask at least one other developer, he might have a better idea for the change)
> 2) Write test good test cases
> I just fixed a method in Graph and removed another one because it was wrong and never used.
> Everybody makes mistakes, but if you write good test cases or ask someone to review changes, it is more likely that we notice them before a release.
> 3) Fix compiler warnings
> I know most of the compiler warnings from gcc can be ignored, but I would prefer fixing them anyway. It is not a big deal and it makes it easier to find important ones.
> I'm happy to discuss those 3 points if you don't agree.
> Bests,
> Marvin
> <ATT00001.c>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20140818/38558bc7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20140818/38558bc7/attachment.sig>

More information about the NetworKit mailing list