Please consider refining (reorganizing/documenting) core headers to aid in their explicit inclusion ...
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- api, embedded-iot
Research direction
The issue does not identify specific files or tests. Start by reviewing the ArduinoCore-API core headers and the Arduino IDE's default project and header-inclusion behavior, then clarify the scope with maintainers. Done would require an agreed approach for explicit baseline headers, preserving existing projects, IDE header inspection, and dependency discovery.
Written by the indexing model from the issue text.
Description
(I don't know if this is the correct place to begin this discussion, but if wrong please move it.)
Specifically I believe the current Arduino development environment is hurting beginners by hiding the inclusion of critical header files, which actually define the API's which programming relies upon, and who's inspection should be encouraged to aid beginners more easily understand why ideally well documented functions must be called with certain argument orders and types for example. Please consider reorganizing and refining Arduino's core library/environment header / implementation specification to allow it to more easily serve as a coherent reference to aid in its use; as also further supported by the following proposed changes:
-
change default new project stationary to include "#include <arduino.h>", which need not be equivalent to "Arduino.h", although will likely include it among other base library headers, defining the base Arduinio API.
-
initially continuing to support their magical inclusion behind the scenes, and thereby not breaking anything for existing projects, but beginning the transition to a requirement for its explicit top-level inclusion.
-
add a feature to the IDE to make it easy to open and view included baseline headers, and those from optionally supported libraries (but possibly kept read-only by default, so beginners don't mistakenly modify them).
-
in turn the source code can then be parsed to determine the code's corresponding library dependency required for compilation and linking, etc.
All visible to the user, as hiding such critical information typically hurts more than helps even, if not especially, beginners understand what's going on and why, in practice.
- Dominant language
- C++
- Stars
- 306
- Forks
- 150
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from arduino/ArduinoCore-API
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
arduino/ArduinoCore-API#261 ·
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 30/100
arduino/ArduinoCore-API#256 ·
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 48/100
arduino/ArduinoCore-API#251 · 1 comment ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
arduino/ArduinoCore-API#250 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
arduino/ArduinoCore-API#249 ·
All issues in arduino/ArduinoCore-API
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·