You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I notice that there is no constraint on line width and even in markdown, lines can be very wide, although GitHub Markdown treats simple line breaks as just white space.
I like to have my code and other text formats confined to a line width that I can print and also view easily in any editor. I even set VS Code to break on a right margin and I clean them up usually. The only exception I can think of is URLs and Markdown links. I am known to put a ruler line at the top of a text file just for this purpose.
Put differently, if I continued to do that (my width magic number is 72) would it still be compatible with the raylib convention? I.e., in a pull request?
The text was updated successfully, but these errors were encountered:
@orcmid That's a good question. At the beginning of raylib I tried to limit line-width to 80 characters but now I prefer to avoid any limit, sometimes I use descriptions or comments longer than 80 characters.
I realized that I had dropped the habit of putting rulers in files, although I do have the auto-linewrap point set in VS Code.
I have gone back and put rulers in files of mine in orcmid/nfoTools and orcmid/rayLab. It is something I must mention in my own CONVENTIONS when I get around to that.
I notice that there is no constraint on line width and even in markdown, lines can be very wide, although GitHub Markdown treats simple line breaks as just white space.
I like to have my code and other text formats confined to a line width that I can print and also view easily in any editor. I even set VS Code to break on a right margin and I clean them up usually. The only exception I can think of is URLs and Markdown links. I am known to put a ruler line at the top of a text file just for this purpose.
Put differently, if I continued to do that (my width magic number is 72) would it still be compatible with the raylib convention? I.e., in a pull request?
The text was updated successfully, but these errors were encountered: