[phase 1] Rename all public methods from camelCase to snake_case

[aregtech]

Important

Refactoring changes should be rebased and merged against this branch:
feature/655-api-modernization-and-refactoring

Summary

Rename all public and protected methods in the AREG SDK framework from camelCase to snake_case to align with the dominant C++ convention (STL, Boost, modern C++ idioms).

Scale

• 149 public classes across the framework
• ~1,479 distinct camelCase method names to rename
• 360 framework source files (176 .hpp + 184 .cpp)
• 203 example files that call these methods
• 18 test files that call these methods

Naming rules

Methods

Current	New
getByteBuffer()	get_byte_buffer()
setSizeUsed()	set_size_used()
isShared()	is_shared()
canShare()	can_share()
invalidate()	invalidate() (already lowercase, no change)
requestHelloService()	request_hello_service()
responseHelloService()	response_hello_service()
serviceConnected()	service_connected()
addIfUnique()	add_if_unique()

Member variables (private/protected)

Style	Convention
Private members	snake_case with m_ prefix: m_byte_buffer
Static members	snake_case with s_ prefix: s_instance_count

Parameters and local variables

Current	New
const String & clientName	const String & client_name
uint32_t startAt	uint32_t start_at

Work order

Process module by module (same order as namespace issue):

1. framework/areg/base/ — core types, containers, threading, I/O
2. framework/areg/component/ — components, proxies, stubs, events
3. framework/areg/ipc/ — inter-process communication
4. framework/areg/logging/ — logging framework
5. framework/areg/persist/ — persistence and configuration
6. framework/areg/appbase/ — application base
7. framework/areg/system/ — system utilities

After framework is done:
8. examples/ — all 29 example projects
9. tests/units/ — all unit tests

Depends on

• Can be done simultaneously with the namespace and prefix issues, or immediately after.
• If done simultaneously, each module PR includes namespace + prefix + snake_case changes together (recommended to minimize churn).

Acceptance criteria

• No camelCase method names remain in the public API
• All method names follow snake_case convention
• Member variables use m_ prefix with snake_case
• All examples compile and run correctly
• All unit tests compile and pass
• Code generator output (if applicable) uses new naming

[fdwr]

Your API is beautiful as-is 🏆. Please don't make it ugly just to be consistent with ancient std practice: 🥲

  Application::loadModel("ServiceModel");
  Application::waitAppQuit(NECommon::WAIT_INFINITE);
  Application::releaseApplication();

std isn't even that self-consistent:

std::ios_base::register_callback - snake_case
std::ios_base::event_callback - snake_case
std::ios_base::fmtflags - mashdtgthercse
std::ios_base::seekdir - abbreviacase
std::ios_base::Init - Pascal case 🙃
std::noboolalpha - mashdtgthercse
std::resetiosflags - mashdtgthercse
std::numpunct - mashdtgthercse
std::do_truename - snake_case AND mashdtgthercse
std::time_put_byname - snake_case AND mashdtgthercse

With extra underscores inserted, now I'd just have to type more, awkwardly reaching with the shift-key plus pinky finger, and readability of individual words within the class names and method names might be faster (service_consumer::service_connected, but overall readability of the logic {seeing methods more as compound words like doghouse rather than sentences of words) suffers. It wouldn't make me not adopt your library, but if two libraries of roughly equal capability existed, I'd definitely choose the cleaner looking one (like C#, Swift, Kotlin, Go, graphics/Qt flavored C++, and not Rust or Google flavored C++).

If you have people asking for snake_case, note you only hear requests that are the opposite of what you already have - you don't typically hear people who already like the way things they are, since they are already content with it. Whatever you do, please don't mix two different styles in the same API, like Upper_Underscore_Case_Struct::letterCaseField or lower_underscore_case_struct::letterCaseField or LetterCaseStruct::snake_case_field or mashedtogethercase::snake_case_fiield. Using snake_case_struct::snake_case_field or Upper_snake_case_struct::snake_case_field or UpperLetterCaseStruct::letterCaseField is harmoniously consistent (like chocolate syrup with ice cream, or ketchup with scrambled eggs), but the former are like mixing ketchup with ice cream.

[aregtech]

Hi @fdwr

thank you for your honest feedback. I really appreciate that.
You are welcome to join this discussion.
The coding style proposal you'll find in this document. Feel free to criticize. All what you said make sense. I'm just trying to find a balance between clarity and modern style :)