Comments (11)
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.
from bric.
I'm also going to be writing a contributing guide too.
from bric.
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!
from bric.
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?
from bric.
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!
from bric.
I would advise everyone to keep checking the projects board (link above) to see what issues and bugs need to be worked on.
from bric.
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.
from bric.
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)
from bric.
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.
from bric.
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.
from bric.
I forgot to mention that Casey has started a bric chat room. All are welcome to join, regardless of contribution level.
from bric.
Related Issues (20)
- Test new undo function HOT 11
- Segmentation Fault while deleting long line. HOT 6
- [suggestion] add support for translations HOT 8
- Quitting in insert mode does not remove lock HOT 5
- Undo function HOT 11
- on the README, update build instructions HOT 1
- lines modified should be modified to support extra plural forms HOT 3
- Host the demo gif somewhere other than this git repo HOT 2
- Fix tab length HOT 2
- Configure the Makefile to build to new build dir HOT 3
- minor string change suggestions HOT 3
- segfault if 'tags' file is wrong format
- add default config file
- code in support to use SYSCONFDIR
- Makefile.am needs noinst_HEADERS section
- Brasilian Portuguese Translation needed HOT 1
- German translation needed HOT 2
- Translate output messages
- Hungarian translation needed HOT 2
- How can I install bric in windows system HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bric.