About code sharing

1

Good day!
Sometimes I want to share my code to ask about problems (really, I will be happy, if somebody use it, but I am look to my skills realistic :slight_smile: ).
To addition to this, I want to see opinions about my programming style - I never worked in the team, so, I don’t sure what my writing right and clear for another peoples.
But I understand what reading someone’s else code is labor. Is something community rules exist to this thing? How many strings of code is already to much for asking help? :slight_smile: How to present it? GitHub + link and all?
And if I need help with some function, but it works in conjunction with my special types and another functions? Sometimes separating it from code for demonstration = make new program with same difficulty, i think (it may be because i am not good in OOP enough).

2

In general, sharing anything is encouraged, and we don’t have a cap on “maximum length” :slight_smile:

There are basically 2 goals for sharing code:

  1. To submit a problem (possible bug in CGE, or maybe a problem in your code).

  2. To get “code review”, to see whether you solve some problem (or maybe your whole game) in a way that we would consider clean/efficient etc.

In both of them, the perfect situation is when you submit a minimal code to achieve the goal (AD 1 - demonstrate the problem, AD 2 - show your solution, in context) but not smaller :slight_smile:

The shorter it is, the easier it is to diagnose the problem (AD 1) or give you a valuable feedback (AD 2).

But we know that things are never perfect :slight_smile: The most important thing is to submit what you have, esp. if it’s possibly a bug in CGE. Don’t worry, we will ask you to make it shorter, if it seems too long.

More notes:

  • For AD 1 (problem report): Share the code (and data) that demonstrates the problem. If the problem is in the CGE editor, then the code doesn’t have to compile (or even exist). If the problem is at runtime, then it has to compile. If the problem is only in a specific environment (OS), make a note about it.

    By sharing a project that is “as small as possible, but still shows the problem” you minimize the effort on our side to diagnose the problem. As a bonus, while minimizing the project, you may also find the problem on your side.

  • For AD 2 (code review): The rules are similar (smaller is better, makes it easier to review) but in this case make sure to show the real context, so that we know your real goal, i.e. what you really want to solve.

    E.g. a “real” goal description is “user should see 1000 humans that perform the same animation, e.g. walking, in a synchronized way”. A bad goal description is “how do I use TPlayAnimationParameters.StopNotification to synchronize 1000 animations” (because in this example, the advise may be “use TimePlayingSpeed, not TPlayAnimationParameters.StopNotification – but ultimately it depends on how you want to synchronize them, by scaling or waiting”). We need to see some context, i.e. real code and real data in which your problem (and solution) live.

  • As for particular way to share: For larger projects, esp. for AD 2, it’s better to put them in some version control, like GitHub or GitLab. Then people can easily grab the project and compile it, can link to particular lines, can even create pull requests / merge requests.

    For smaller things, esp. for AD 1, just posting a zip with project (or even a code snippet, if it’s just a trivial modification to e.g. one of CGE examples/templates) is of course OK.

  • If you suspect you have a CGE bug, it’s best to submit it to Issues · castle-engine/castle-engine · GitHub (esp. if you don’t get an answer on the forum right away). It’s easier to track down unresolved problems this way.

1 Like