Code Use AI

Item	Convention	Example
Files	snake_case	`my_module.rs`, `user_service.rs`
Modules	snake_case	`mod user_authentication;`
Types (structs, enums, traits)	UpperCamelCase (PascalCase)	`MyStruct`, `HttpRequest`
Functions	snake_case	`calculate_total()`, `get_user()`
Variables	snake_case	`user_name`, `total_count`
Constants	SCREAMING_SNAKE_CASE	`MAX_SIZE`, `DEFAULT_TIMEOUT`
Static variables	SCREAMING_SNAKE_CASE	`GLOBAL_CONFIG`
Type parameters	UpperCamelCase (concise)	`T`, `E`, `K`, `V`
Lifetimes	lowercase, short	`'a`, `'b`, `'static`
Macros	snake_case!	`println!`, `vec!`

C++ Language Naming Conventions

Unlike Rust, C++ does not have a single, universally enforced naming convention. Different organizations
and style guides use different conventions. However, there are common patterns and several widely-adopted
style guides that provide consistency within projects.

⚠️ Important Note

C++ naming conventions vary significantly across different codebases and organizations. The most
important thing is to be consistent within your project and follow your team's
chosen style guide. Below are the most common conventions.

Common Naming Patterns

Item	Common Conventions	Examples
Files	snake_case or PascalCase	`my_class.cpp`, `MyClass.cpp` `my_class.h`, `MyClass.h`
Header Files	.h, .hpp, .hxx	`myclass.h`, `myclass.hpp`
Classes/Structs	PascalCase or snake_case	`MyClass`, `HttpRequest` `my_class`, `http_request`
Functions/Methods	camelCase, PascalCase, or snake_case	`calculateTotal()`, `CalculateTotal()` `calculate_total()`
Variables (local)	snake_case or camelCase	`user_count`, `userCount`
Member Variables	Various (see details below)	`m_data`, `data_`, `_data`, `mData`
Constants	SCREAMING_SNAKE_CASE or kPascalCase	`MAX_SIZE`, `kMaxSize`
Macros	SCREAMING_SNAKE_CASE	`MY_MACRO`, `DEBUG_MODE`
Namespaces	snake_case or lowercase	`my_namespace`, `myproject`
Template Parameters	PascalCase or single letter	`T`, `ValueType`, `Iterator`
Enums	PascalCase (type) + PascalCase or SCREAMING (values)	`enum Color { Red, Green }` `enum Color { RED, GREEN }`

Detailed Conventions

Files

Headers: Use .h, .hpp, or .hxx extensions
Implementation: Use .cpp, .cc, or .cxx extensions
File names often match class names: MyClass.h and MyClass.cpp
Some projects use lowercase with underscores: my_class.h

Classes and Structs

Most common: PascalCase (UpperCamelCase)
STL-style: snake_case (less common outside STL)
Should be nouns or noun phrases

class UserAccount { ... };
struct HttpRequest { ... };
class DatabaseConnection { ... };

Functions and Methods

Google Style: PascalCase - CalculateTotal()
STL Style: snake_case - calculate_total()
Microsoft Style: PascalCase - CalculateTotal()
camelCase: Less common but used in some projects - calculateTotal()
Getters often omit "get": name() not getName() (STL style)
Boolean functions often prefixed: is_valid(), has_data()

// Google/Microsoft style
void ProcessData();
bool IsValid() const;

// STL style
void process_data();
bool is_valid() const;

Variables

Local variables: snake_case or camelCase
Global variables: Often prefixed with g_: g_app_state
Should be descriptive nouns

int user_count = 0; // snake_case
int userCount = 0; // camelCase
int g_global_counter = 0; // global with prefix

Member Variables (Class Data Members)

Multiple conventions exist - choose one and be consistent:

m_ prefix: m_data, m_count
Trailing underscore: data_, count_
Leading underscore: _data, _count (avoid - reserved in some contexts)
Hungarian-style prefix: mData, mCount
No prefix (requires care to avoid shadowing): data, count

class MyClass {
private:
    int m_count; // m_ prefix
    string name_; // trailing underscore
    double mValue; // Hungarian-style
};

Constants

const variables: Often kPascalCase or SCREAMING_SNAKE_CASE
constexpr variables: Same as const
Enum values: PascalCase or SCREAMING_SNAKE_CASE

const int kMaxConnections = 100; // Google style
const int MAX_CONNECTIONS = 100; // Traditional style
constexpr double kPi = 3.14159;

Macros and Preprocessor Definitions

Always use SCREAMING_SNAKE_CASE
Often prefixed with project name to avoid collisions
Include guards use ALL_CAPS with underscores

#define MAX_BUFFER_SIZE 1024
#define MY_PROJECT_VERSION "1.0"

#ifndef MY_CLASS_H_
#define MY_CLASS_H_
// ...
#endif // MY_CLASS_H_

Namespaces

Use snake_case or all lowercase
Should be short and descriptive
Often match project or module names

namespace myproject {
namespace utils {
void helper_function();
}
}

Template Parameters

Single letter for simple cases: T, U, V
Descriptive PascalCase for complex cases: ValueType, Allocator
Common conventions: T for type, N for size, Pred for predicate

template <typename T>
class Container { ... };

template <typename KeyType, typename ValueType>
class Map { ... };

Enums and Enum Classes

Enum type name: PascalCase
Enum values: PascalCase or SCREAMING_SNAKE_CASE
enum class (C++11+) recommended over plain enum

enum class Color {
    Red,
    Green,
    Blue
};

enum Status {
    STATUS_OK,
    STATUS_ERROR
};

Popular C++ Style Guides

Google C++ Style Guide

Functions: PascalCase - MyFunction()
Variables: snake_case - my_variable
Classes: PascalCase - MyClass
Constants: kPascalCase - kMaxValue
Member variables: Trailing underscore - member_

LLVM Coding Standards

Functions: camelCase - myFunction()
Variables: PascalCase - MyVariable
Classes: PascalCase - MyClass
Member variables: PascalCase - MemberVar

C++ Core Guidelines

Flexible but recommends clarity and consistency
Focus on modern C++ practices
No strict naming requirements but suggests STL-like conventions

STL/Standard Library Style

Everything: snake_case
Classes: snake_case - std::vector
Functions: snake_case - push_back()
Very consistent but less common in application code

Important Considerations

Reserved Names

Avoid double underscores __ anywhere (reserved for compiler)
Avoid leading underscore followed by capital letter: _MyVar (reserved)
Avoid single leading underscore in global scope: _global (reserved)

Consistency is Key

Choose one style guide and stick to it throughout your project
Document your team's chosen conventions
Use linters and formatters (clang-format, clang-tidy) to enforce consistency
When contributing to existing projects, match their existing style

Modern C++ Considerations

Prefer enum class over plain enum
Use constexpr instead of macros when possible
Consider using inline variables (C++17) for constants in headers
Namespace your code to avoid global naming conflicts

Bottom Line:
Unlike Rust, C++ has no enforced standard. The most important thing is to choose a style guide
(Google, LLVM, your own) and apply it consistently across your codebase. Use automated tools
to help enforce your chosen conventions.

C# Language Naming Conventions

C# has well-established naming conventions defined by Microsoft in the official .NET design guidelines.
These conventions are widely adopted across the C# ecosystem and are considered best practices for
writing clean, maintainable code.

Summary Table

Item	Convention	Example
Files	PascalCase (match type name)	`MyClass.cs`, `UserService.cs`
Namespaces	PascalCase	`MyCompany.MyProduct.MyFeature`
Classes	PascalCase	`CustomerAccount`, `HttpClient`
Interfaces	PascalCase with I prefix	`IDisposable`, `IEnumerable`
Methods	PascalCase	`GetUser()`, `CalculateTotal()`
Properties	PascalCase	`FirstName`, `IsActive`
Events	PascalCase	`ButtonClicked`, `DataReceived`
Fields (public/protected)	PascalCase	`MaxValue`, `DefaultTimeout`
Fields (private)	camelCase or _camelCase	`userName`, `_userName`
Constants	PascalCase	`MaxConnections`, `Pi`
Parameters	camelCase	`userId`, `firstName`
Local Variables	camelCase	`userCount`, `totalPrice`
Enums	PascalCase (type and values)	`Color.Red`, `Status.Active`
Type Parameters	PascalCase with T prefix	`T`, `TKey`, `TValue`
Async Methods	PascalCase with Async suffix	`GetUserAsync()`, `SaveDataAsync()`

Detailed Conventions

Files and Folders

Use PascalCase for file names
File names should match the primary type (class/interface/struct) they contain
Use .cs extension for all C# source files
Folder names typically use PascalCase

// File: CustomerAccount.cs
public class CustomerAccount { ... }

Namespaces

Use PascalCase for all namespace components
Follow pattern: CompanyName.ProductName.Feature.SubFeature
Use meaningful, hierarchical names
Avoid single-word namespaces (except for company/product)

namespace MyCompany.ECommerce.Orders
{
public class OrderProcessor { ... }
}

Classes, Structs, and Records

Use PascalCase
Use nouns or noun phrases
Do not use prefixes (e.g., C for class)
Be descriptive and avoid abbreviations

public class CustomerAccount { ... }
public struct Point3D { ... }
public record Person(string FirstName, string LastName);

Interfaces

Use PascalCase with I prefix
Use adjectives or noun phrases
Adjective names often end with "able": IDisposable, IComparable

public interface IRepository { ... }
public interface IDisposable { ... }
public interface ICustomerService { ... }

Methods

Use PascalCase
Use verb or verb phrases
Async methods should end with Async suffix
Test methods often use underscores for readability (exception to PascalCase)

public void ProcessOrder() { ... }
public string GetUserName() { ... }
public async Task<User> GetUserAsync(int id) { ... }

// Test method (common pattern)
[Test]
public void CalculateTotal_WithDiscount_ReturnsCorrectValue() { ... }

Properties

Use PascalCase
Use nouns or noun phrases
Boolean properties often start with "Is", "Has", "Can", "Should"
Avoid "Get" or "Set" prefixes (that's what methods are for)

public string FirstName { get; set; }
public int Age { get; set; }
public bool IsActive { get; set; }
public bool HasPermission { get; private set; }

Fields

Public/Protected fields: PascalCase (rare - prefer properties)
Private fields: camelCase or _camelCase (underscore prefix)
Underscore prefix helps distinguish fields from local variables
Be consistent within your codebase

public class Example
{
    // Private fields - choose one style
    private string _userName; // Microsoft style (recommended)
    private string userName; // Alternative style

    // Public field (avoid - use property instead)
    public int MaxValue;
}

Constants and Read-Only Fields

Use PascalCase (not SCREAMING_SNAKE_CASE like in C/C++)
Applies to both const and static readonly
Use meaningful names that describe the value's purpose

public const int MaxConnections = 100;
public const double Pi = 3.14159;
public static readonly string DefaultCulture = "en-US";

Parameters and Local Variables

Use camelCase
Use descriptive names, avoid single letters (except in loops)
Discard variables use underscore: _

public void ProcessUser(int userId, string firstName)
{
    int userCount = 0;
    string fullName = firstName + " " + lastName;

    for (int i = 0; i < 10; i++)
    {
        // ...
    }

    // Discard
    if (TryParse(input, out _))
    {
        // ...
    }
}

Enums

Enum type: PascalCase
Enum values: PascalCase
Use singular names for enums (unless bit flags)
Use plural names or [Flags] attribute for bit flag enums

public enum Color
{
    Red,
    Green,
    Blue
}

[Flags]
public enum FilePermissions
{
    None = 0,
    Read = 1,
    Write = 2,
    Execute = 4
}

Events

Use PascalCase
Use verb phrases (present or past tense)
Use "Before" and "After" for pre/post events: Opening/Opened
Event handlers typically named: OnEventName

public event EventHandler ButtonClicked;
public event EventHandler DataReceived;
public event EventHandler<CancelEventArgs> WindowClosing;

protected virtual void OnButtonClicked(EventArgs e)
{
ButtonClicked?.Invoke(this, e);
}

Type Parameters (Generics)

Use PascalCase with T prefix
Single letter for simple cases: T
Descriptive names for complex cases: TKey, TValue, TResult

public class List<T> { ... }
public class Dictionary<TKey, TValue> { ... }
public interface IRepository<TEntity> where TEntity : class { ... }

Delegates

Use PascalCase
Event handler delegates end with EventHandler
Other delegates use descriptive names with optional Callback or Func suffix

public delegate void ProcessCompleteEventHandler(object sender, EventArgs e);
public delegate bool ValidationCallback(string input);

Attributes

Use PascalCase
End with Attribute suffix
The suffix is optional when applying the attribute

public class ValidationAttribute : Attribute { ... }

// Usage (suffix optional)
[Validation]
[ValidationAttribute] // Same as above
public class MyClass { ... }

Best Practices and Additional Guidelines

Abbreviations and Acronyms

Two-letter acronyms: both uppercase in PascalCase: IO, UI
Three+ letter acronyms: only first letter uppercase: Html, Xml, Json
Exception: When acronym is at the start of camelCase identifier, all lowercase: htmlDocument

public class IOHelper { ... } // Two-letter
public class HtmlParser { ... } // Three+ letters
public class XmlDocument { ... }

string htmlContent = ""; // camelCase with acronym
IDbConnection dbConnection = null;

Boolean Naming

Use affirmative phrases: IsValid not IsNotValid
Common prefixes: Is, Has, Can, Should, Supports
Make the meaning clear: IsEnabled is clearer than Enabled

public bool IsActive { get; set; }
public bool HasChildren { get; set; }
public bool CanExecute { get; set; }
public bool ShouldRetry { get; set; }

Async/Await Pattern

Async methods must end with Async suffix
Return Task or Task<T>
Avoid async void except for event handlers

public async Task<User> GetUserAsync(int id)
{
return await database.GetUserAsync(id);
}

public async Task SaveDataAsync()
{
await database.SaveChangesAsync();
}

Collection Naming

Use plural nouns: Users, Orders, Items
Or descriptive noun: UserList, OrderCollection
Avoid generic names like "List" or "Array" alone

public List<User> Users { get; set; }
public IEnumerable<Order> ActiveOrders { get; set; }
public Dictionary<int, Customer> CustomerCache { get; set; }

Extension Methods

Use PascalCase like regular methods
Place in static classes with descriptive names ending in "Extensions"
Make the purpose clear in the method name

public static class StringExtensions
{
    public static bool IsNullOrEmpty(this string value)
    {
        return string.IsNullOrEmpty(value);
    }
}

Official Resources and Tools

Microsoft Guidelines

Follow the official .NET Design Guidelines
Microsoft's Framework Design Guidelines book provides comprehensive coverage
StyleCop and Roslyn analyzers enforce many of these conventions

Code Analysis Tools

StyleCop: Enforces naming and style conventions
Roslyn Analyzers: Built-in Visual Studio code analysis
EditorConfig: Define and maintain consistent coding styles
ReSharper: Provides extensive naming and style suggestions

EditorConfig Example

[*.cs]
# Naming conventions
dotnet_naming_rule.private_fields_rule.severity = warning
dotnet_naming_rule.private_fields_rule.symbols = private_fields
dotnet_naming_rule.private_fields_rule.style = underscore_camel_case

Consistency Within Teams

Document your team's conventions in a style guide
Use automated formatters and analyzers to enforce consistency
Private field convention (with or without underscore) should be consistent
Review and update conventions as the language evolves

Key Takeaway:
C# has very well-defined and widely-adopted naming conventions. Following Microsoft's official guidelines
ensures your code is readable and maintainable, and integrates well with the broader .NET ecosystem.
Use automated tools to enforce these conventions consistently.

Item	Convention	Example
Files/Modules	snake_case, short, lowercase	`my_module.py`, `user_service.py`
Packages	snake_case or lowercase, short	`mypackage`, `my_package`
Classes	PascalCase (CapWords)	`MyClass`, `UserAccount`
Exceptions	PascalCase, end with "Error"	`ValueError`, `ConnectionError`
Functions	snake_case	`calculate_total()`, `get_user()`
Methods	snake_case	`process_data()`, `is_valid()`
Variables	snake_case	`user_count`, `total_price`
Constants	SCREAMING_SNAKE_CASE	`MAX_SIZE`, `DEFAULT_TIMEOUT`
Private attributes	_leading_underscore	`_internal_value`, `_helper()`
Name mangling	__double_leading_underscore	`__private_var`
Magic methods	__double_underscores__	`__init__`, `__str__`
Type variables	PascalCase, short	`T`, `KT`, `VT`

Pros and Cons of Using AI Tools for Code Development

Increased Productivity

Learning and Problem-Solving

Code Quality Improvements

Reduced Cognitive Load

Accuracy and Reliability Issues

Security and Quality Risks

Over-Reliance Concerns

Legal and Licensing Questions

Context Limitations

Cost Considerations

Can AI Tools Be Used to Refactor Existing Code?

What AI Can Do Well for Refactoring

Pattern Recognition and Improvements

Structural Changes

Language and Framework Updates

Documentation and Type Safety

Practical Approach

Limitations to Watch For

Can AI Be Used to Write Unit Tests?

What AI Does Well for Unit Testing

Test Generation

Coverage Improvements

Test Patterns and Best Practices

Existing Test Enhancement

Where AI Struggles

Complex Business Logic

Integration and System Tests

Test Quality

Context and Intent

Best Practices for AI-Generated Tests

Start Small

Review and Validate

Provide Good Context

Combine with Manual Testing

Iterate and Improve

Example Use Cases

Can AI Tools Be Used to Scan Code Files for Security Vulnerabilities?

What AI Can Do Well for Security Scanning

Pattern Recognition and Common Vulnerabilities

Code Analysis and Review

Dependency and Configuration Issues

Contextual Understanding

Common Vulnerabilities AI Can Detect

Injection Attacks

Cross-Site Scripting (XSS)

Authentication and Session Issues

Data Exposure

Access Control Issues

Cryptographic Failures

Limitations and Challenges

False Positives and Negatives

Context and Architecture Understanding

Advanced and Emerging Threats

Language and Framework Coverage

Environmental and Deployment Issues

Best Practices for Using AI for Security Scanning

Layered Security Approach

Integrate Early and Often

Provide Good Context

Validate and Prioritize Findings

Continuous Improvement

AI-Powered and Complementary Security Tools

AI-Enhanced Security Tools

Traditional SAST Tools (Often Combined with AI)

Dependency Scanning Tools

Secret Scanning Tools

Dynamic and Interactive Testing

Example Use Cases

Pre-Commit Scanning

Code Review Assistance

Legacy Code Auditing

Security Training

Important Security Considerations

Never Rely Solely on AI

Privacy and Data Handling

Keep Security Knowledge Current

Regulatory and Compliance Requirements

Can AI Be Used to Generate Code Documentation?

Types of Documentation AI Can Generate