Encapsulate hue.cpp's own runtime state as static, not global - #5777
Open
netmindz wants to merge 1 commit into
Open
Encapsulate hue.cpp's own runtime state as static, not global#5777netmindz wants to merge 1 commit into
netmindz wants to merge 1 commit into
Conversation
11 WLED_GLOBAL variables (hueXLast, hueYLast, hueHueLast, hueCtLast, hueSatLast, hueBriLast, hueLastRequestSent, hueAuthRequired, hueReceived, hueNewKey, hueClient) turned out to be referenced only in hue.cpp - nowhere else in wled00/ or usermods/ touches them. They were global purely because everything in wled.h lives in one big extern block regardless of who actually uses it. Converted all 11 to file-local `static` in hue.cpp. hueStoreAllowed, which was declared on the same line as hueNewKey, stays global since set.cpp also writes it. No behavior change - purely a storage-class change, same types and initial values as before. Verified: esp32dev builds and links cleanly via `pio run -e esp32dev` (1,320,323 bytes flash, no warnings from the changed files). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UtCyBD91vAYWvBzaMyQSHd
Contributor
WalkthroughHue synchronization state moved from public declarations in ChangesHue state encapsulation
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This was referenced Aug 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
11
WLED_GLOBALvariables declared inwled.hturned out to be referenced only inhue.cpp— nowhere else inwled00/orusermods/touches them:hueXLast,hueYLast,hueHueLast,hueCtLast,hueSatLast,hueBriLast,hueLastRequestSent,hueAuthRequired,hueReceived,hueNewKey,hueClient. They were global purely because everything inwled.hlives in one bigexternblock regardless of who actually uses it.Converted all 11 to file-local
staticinhue.cpp, with the same types and initial values as before.hueStoreAllowed, which was declared on the same source line ashueNewKey, stays global sinceset.cppalso writes it — verified by grep before splitting that declaration.No behavior change — purely a storage-class change, nothing else touched.
This is a small, mechanical first step from a broader pass identifying which of WLED's ~270
WLED_GLOBALdeclarations are actually only used in one file (this is the largest single-file cluster).Test plan
esp32dev: builds and links cleanly viapio run -e esp32dev— 1,320,323 bytes flash, no warnings from either changed file.wled00/,usermods/) that none of the 11 converted variables are referenced outsidehue.cpp.🤖 Generated with Claude Code
Summary by CodeRabbit