How do you allow others to trust your code and use it?

I write hobby code from time to time. The fact is that these tools, classes or tiny code libraries end up in a flash drive with a hopeless future! I would like to continue developing my projects and let other programmers trust them. If you are going to use something that you found on the Internet, what is the most important thing that you are looking for in this software tool or small library? For example, would you consider separate documentation as well?


Thanks for all the contributors. I will try my best to summarize what has been said. Feel free to modify the list. Corrections and additions are more welcome :)

+4
source share
8 answers

Get the blog, enter the code in it. Explain why you wrote it, what problem it solves. And encourage others to improve it, leave the code as relevant as possible. If your tools are useful, you will very quickly develop the following that “trusts” your code.

Separate documentation is not required for small tools, but anything that falls into the world should probably have sufficient documentation and examples if you want to get serious recognition from the community at large.

+7
source

Most importantly, the library is that it is open source, so I can read the code myself. If this is not possible, I insist on documentation.

Also consider using a site to host a project (e.g. google or github code).

+3
source
  • You have a clear license with your code if you do not have one (preferably one that encourages code change / improvement / exchange ...)

  • You have open version control and / or a public bug / problem tracker and / or mailing list. There are many good sites that offer these services for free.

  • Separate documentation is not a decisive factor for me (if the code is well documented and the quality of the code is high).

+2
source
  • Documentation explaining why you wrote it when you started it, and it is for the function. Understanding where you came from will allow me to see future ideas, as well as a short coming that you may not have seen.
  • Technical documentation explaining the API and some examples of how to implement it. Ideally, keep your documentation in a format that follows the language. For example, C # tends to use XML syntax to define elements. It makes me feel at home when I read it.
  • Pure code - I can't stress this because too many people write exceptionally ugly code. If you code is ugly and / or unreadable, it might be easier for me to write it from scratch myself. At least make your code consistent. If I cannot understand the code, I will not feel comfortable with it.
  • Historical records explaining your changes. Seeing how the project has grown, I can better plan. It also allows people to see how you learn from your mistakes and feel your level of skill. Compared to the forum, you can feel how quickly everything is fixed and then placed in the new version.
  • Think long and hard about which license you want there. The commons? BSD? GPL? More restrictive?
  • A note about whether you have the opportunity to contact you or if there are any restrictions. For example, could you mind the updates? Am I explaining security holes? Or maybe you can use a forum or a wiki?
  • An opportunity to get the latest work and / or nightly assembly. SVN or something else. This is useful, so I know that the error found is already fixed.
+2
source

I think the documentation is the key to your project.

The document must indicate:

  • What is the purpose of your library.
  • what are the main functions
  • a really short tutorial so that it starts in 5 minutes.
  • Many examples
+1
source

I allow people to trust my code in a number of projects, but I encourage people to create and maintain their own tests, and I am sure that I am satisfied with unit tests.

The documentation is always good, but it's my fault that I took the time to do as much as I wanted. But having an author quite contactable is helpful.

+1
source

Posting it to an open source repository such as code.google.com or sourceforge.net is probably where to start ...

Further, to attract attention, clearly and clearly state the purpose of the library / application as a scheme in one of the answers above.

Finally, blogs and direct mail exchanges take place ...

+1
source

One of the reasons documentation helps people trust your code is because they know if this function is something you intended to do for this code (and which, all other things being equal, will be saved in future versions code), or that the current code just happens, but that can change at any time as a side effect of a fix or just refactoring.

Some people prefer to find out what code really does by looking at it, and that’s fine, but the documentation tells you (a) what the code should do, and with some luck (b) that I’ll do the next version of the code. If I want to use my code for a long time and accept updates for corrections, as you have provided them, then I need to know that you have developed an interface that I can rely on, and which you are ready to stick to. Documentation is a strong hint that you are at least trying to do this.

+1
source

All Articles