Source code organization

[HomeACcessoryKid]

This is my first GitHub project and also writing c-code for ESP_RTOS is a first time.

In order to make this project as accessible as possible to others, help to suggest how to setup the directory structure and include structures etc... in a better way

Thanks in advance, HacK

[danicarrion]

I'd move all the licensing stuff to the LICENSE file, so that it doesn't pollute the rest of the files.

Apart from that, source code requires cleaning (like, getting rid of commented-out code) and some function definitions aren't documented, which makes it hard for me to figure out what they're about (the fact that I'm not at all familiar with this architecture doesn't help, touché). Adhering to some style guide would help too (maybe Google's?) or, at least better consistency in code syntax.

Also, contents of the todo.txt file should be transferred to Github issues.

I'm afraid I can't help with folder structure or give any more advanced feedback, as I'm not familiar with the IDE/tool chain.

My two cents :-)

[HomeACcessoryKid]

Thanks Dani, Your input is much appreciated and we'll work on improving these items. The license info however is supposed to be in each file if you believe the instructions of the gnu license pages https://www.gnu.org/licenses/gpl-howto.html

[HomeACcessoryKid]

I am leaning to the following approach: There will be two repo's:

1. ESP8266-HomeKit -- contains the framework with crypto and gives lib/libhkc.a + include/hkc.h
2. ESP8266-HomeKit-Demo -- contains the user code and needs lib/libhkc.a + include/hkc.h

Disadvantage is that the framework is useless without the Demo.
Advantages

• separating the API
• updating the pieces independently is so much cleaner
• crypto does not need to be included at the Demo level anymore
• the setup instructions would be a lot easier to understand

I'm trying the proof of the concept and if it works will push it through

Meanwhile, you can share your opinion on the subject. PS. I've discarded submodules since it seems to have many pitfalls in a multi person situation

[AdySan]

@danicarrion Can you elaborate on this a little? Do you recommend creating separate issues for each item of just a simple task list in a single issue?

Also, contents of the todo.txt file should be transferred to Github issues.

[HomeACcessoryKid]

Just did the restructure... updating documentation...

[HomeACcessoryKid]

changed all tabs to 4 spaces and made the license banner a bit nicer

[danicarrion]

@AdySan I'd create one issue per item. That way, anyone can fork, work on that issue, make a PR and contribute back in a very organized way.