Skip to main content

User login

What is OpenID?
  • Log in using OpenID
  • Cancel OpenID login
  • Create new account
  • Request new password
Register
  • Home
  • Browse
    • 2D Art
    • 3D Art
    • Concept Art
    • Textures
    • Music
    • Sound Effects
    • Documents
    • Featured Tutorials
  • Submit Art
  • Collect
    • My Collections
    • Art Collections
  • Forums
  • FAQ
  • Leaderboards
    • All Time
      • Total Points
      • Comments
      • Favorites (All)
      • Favorites (2D)
      • Favorites (3D)
      • Favorites (Concept Art)
      • Favorites (Music)
      • Favorites (Sound)
      • Favorites (Textures)
    • Weekly
      • Total Points
      • Comments
      • Favorites (All)
      • Favorites (2D)
      • Favorites (3D)
      • Favorites (Concept Art)
      • Favorites (Music)
      • Favorites (Sound)
      • Favorites (Textures)
  • ❤ Donate
FLARE

Coding Standards

ircnet
Friday, July 8, 2011 - 13:30

Thinking it might be a good idea to put together a coding standards document as seen in other open source projects.

It would dictate the formatting standards of the code among other things, and help us to maintain a consistently readable codebase.

Not that we really need it right now as as far as I can see we are working well together but the project is growing fast in my eyes.

What does anyone else think?

  • Log in or register to post comments
Clint Bellanger
joined 13 years 6 months ago
Saturday, July 9, 2011 - 21:41
Clint Bellanger's picture

I keep an eye out for coding style before I approve Pull Requests -- if something is implemented in a funky or confusing way I'll ask for a revision before approving. I'm not too picky though.

What could definitely be useful is some code house-cleaning, e.g. add javadoc style comments to all functions. I know soon we'll be making a pass to move all magic numbers to constants, and possibly into config files (that's what the /engine/ folder is for). Some standardizing on function/variable names etc. could help.

I think there's going to be quite a lot of code hacking with this translations/mods/unicode work coming up, so maybe after that is done we can make a cleaning pass.

 

 

 

  • Log in or register to post comments
ircnet
joined 11 years 10 months ago
Monday, July 11, 2011 - 10:09

Ok sounds good

  • Log in or register to post comments
Alexey Petrushin
joined 11 years 10 months ago
Monday, July 18, 2011 - 15:02

A little offtopic, but maybe it will be useful.

I looked at the code of Flare and vas very impressed that it's clean and has small size (I don't know C++ and can't write it, but can read it).

And I didn't noticed there any usage of specs or tests. 

It's a tools that save developer time spend on tests and allows developer to safely do code update and refactoring (without broke old functionality).

It's also usefull when there are multiple people working on the project and they need a way to be shure that their changes doesn't broke another people's code.

I'm not sure does the Flare need such a tools right now, but maybe it will be useful.

  • Log in or register to post comments
Clint Bellanger
joined 13 years 6 months ago
Tuesday, July 19, 2011 - 09:42
Clint Bellanger's picture

Thanks about the code. Yeah surprisingly this type of game doesn't require a crazy amount of code. I've taken efforts to keep it readable. Also it helps that Flare has a specific duty (action RPG) instead of trying to be a do-all-things game engine.

I'd love to add automated unit tests and regression testing. Some unit testing should be easy to set up. Testing interface or combat stuff seems tricker, and that's probably where the trickier bugs will appear.

  • Log in or register to post comments
Anonymous (not verified)
joined 0 sec ago
85.151.56.227
Friday, January 6, 2012 - 13:07

I know this thread is old, but I'd like to second the proposal to put a document together.  Particular things I'd like to see addressed:

  • Policy on exceptions
  • Policy on .at() as opposed to .operator[] -- all the code uses the former, should new code comply?
  • List of libraries that may be used (including the status of C++11, and tr1)
  • Is there some kind of rule about explicitly calling close() on files, and checking is_open() before that?  I've seen it in a few places -- is it for compatibility with some platform?
  • What should be done in cases when we know something went horribly wrong?
  • WidgetButton is generally dynamically allocated, while WidgetLabel is sometimes just a member -- why?
  • Should anything be done about class members that the constructor leaves uninitialised?  (There's a few classes that do this, but I'm not sure if it's intentional.)
  • When should we use streams, and when should we use printf?

There's no hurry, but it would make it easier  for newcomers to start contributing.

  • Log in or register to post comments