potassco / potassco/constraint-handler

Conventions for asp names

Open
#59 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
3
Forks
0
Avg merge
1d 19h
Merged PRs (30d)
20

Description

The asp code is organized around conceptual modules. It should strive to adhere to the following conventions

the name of user-facing / interface predicates should

  • optionally start with a module name followed with an underscore _
  • use mixed case

the name of cross-module predicates should

  • start with a module name
  • follow with an underscore _
  • end with the name of the concept the predicate stands for, in mixed case

the name of predicates internal to a module should

  • start with an underscore _
  • follow with a module name
  • follow with an underscore _
  • end with the name of the concept the predicate stands for, in mixed case

the name of grounding/meta variables should

  • be written an all caps
  • separate words with underscores.

Example:

  • optimize_maximizeSum and optimize_precision are two interface predicates from the optimize module.
  • _set_foldStep is an internal predicate from the set module.
  • in the following snippet, the predicate _main_defaultEngine is internal to the main module whereas defaultEngine is intended to be user-facing, and ENG is a grounding variable.
_main_defaultEngine(ENG) :- defaultEngine(ENG).
_main_defaultEngine(compile) :- not defaultEngine(_).

Naming conventions for function symbols have not been decided yet.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named in the issue. Start by inventorying predicate names across the ASP modules and comparing them with the listed interface, cross-module, internal, and grounding-variable rules. Done means the applicable conventions are documented or adopted consistently, with a separate decision for function-symbol naming.

Written by the indexing model from the issue text.

Assessment

Domain
developer-experience
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.