The Road Ahead

[shnupta]

The Road Ahead

[anfly0]

On the "style guidelines" topic:
I stumbled across this: https://users.ece.cmu.edu/~eno/coding/CCodingStandard.html
At least parts of it could serve as a basis for both style guidelines and a more general coding standard.
In any case it's a good read for anyone that want's to revisit some of the "old truths" regarding good C-code practices.

[shnupta]

I'm also going to be writing a contributing guide too.

[doztrock]

Hey! I think it would be great if the code is separated :D It would help to avoid conflicts, maybe I could suggest some editor with "code beautify" like Netbeans or VSCode. We could try to use it to develop. Also I could handle something about separate files. After my pull-request acceptation :D

I think, well, I propose like an idea to separate the files, something like:

Foreach feature, we could separate the *.c file, not the *.h, because the header is not changed frequently but the source files.

Something like:

-We have Low level terminal handling, so I think we could create a file terminal.c to content the functions is_separator(), editing_row_has_open_comment(), etc.

-We have Syntax highlighting, so I think we could join all these functions in a file highlight.c, to content the related functions. is_separator(), etc.

And we could leave just bric.h, it's just a header, it must content the prototypes, structs, enums, constants, etc. Something who is not changed all the time like functions.

I hope to know your opinion about my idea. Hope it helps!

[bleepcord]

Contribution guide would be a great idea. Also include style guidelines because I've noticed some mixed tabs and spaces that I would love to clean up :) I'm even willing to take care of it once we have a style guide. Unless you decide to use a beautifier.

I also think @doztrock's plan is perfectly reasonable. I would only add that in my opinion it's preferable to have a header file for each .c file (within reason). It would prevent bric.h from becoming cluttered and it would organize prototypes, enums, etc. based on their relevant implementations.

I also do not think forcing a specific editor for development of bric is a good idea. It would deter future contributors. We can use an alternative code beautifier if it's really desired. Perhaps Uncrustify?

[shnupta]

HI @doztrock and @bleepcord ,

I think once #69 has been merged I will merge the vim-change branch to the master and we shall start the refactor and development moving forward from there.

I agree with @bleepcord's suggestion that we shouldn't be editor specific simply to allow new contributors to get involved without much hassle.

I also think we should separate into header files too although this will require a bit more thought than separating the source files as code from bric.h is used in a lot of places. We will probably have to discuss the splitting up of the header file in a separate issue.

@doztrock's examples for different source files seems like a good idea to get started.

@bleepcord I'll check out Uncrustify a bit more in a couple days and see whether it may be a good fit or not.

Thank you both very much!

[shnupta]

I would advise everyone to keep checking the projects board (link above) to see what issues and bugs need to be worked on.

[andy5995]

Well there are many coding styles to choose from. I usually go with GNU because I've been a GNU Linux user for so many years. And sometimes I use indent to auto-format, and it has options to format using different styles, such as K&R and GNU.

But yes, I agree one must be decided upon.

[shnupta]

K&R is probably my preferred style but that doesn't say it has to be that. When I have a spare moment I'll run the source through indent and see how it comes out.

It will also be worth checking that the naming of variables and functions is consistent (I highly doubt I paid much attention to that when I wrote it.... bad me 2 years ago)

[andy5995]

Also I'd suggest a maximum line length of 80, but making exceptions for lines up to 100. I think indent does that automatically. Makes the code easier to read.

As for indenting, I typically use 2 spaces not 4. That helps keep the width of the lines down when there are many nested code blocks.

And I do prefer spaces not tabs these days, because it renders on GitHub diffs more accurately.

[andy5995]

I'm also going to be writing a contributing guide too.

This is now done

https://github.com/shnupta/bric/blob/master/CONTRIBUTING.md

Also include style guidelines because I've noticed some mixed tabs and spaces that I would love to clean up :)

All spaces now, @bleepcord :)

I'm even willing to take care of it once we have a style guide. Unless you decide to use a beautifier.

We did. :) That type of change is usually best left to maintainers. What happens is that when the changes are reviewed, the diff file can be over 1000 lines so it's much easier to "review" if it's only done by one or 2 people.

Anyone is still welcome to leave feedback about the new code format. I'll leave this issue closed (Casey has appointed me to help him be a co-maintainer until he has more free time), but if there's anything specific related to this ticket that still needs to be addressed, let's open individual tickets for that.

Thanks to everyone for participating in this discussion. We hope we covered all the main points with recent commits. Everything is now on the master branch and we will be deprecating the development and testing branch.

[andy5995]

I forgot to mention that Casey has started a bric chat room. All are welcome to join, regardless of contribution level.