vb6-guidelineslisted

Applies general Visual Basic 6 conventions when editing .bas, .cls, .frm, .frx, .vbp, .vbg, .ctl, or .dob files, or any code identified as VB6 (not VB.NET, not VBA). Covers case-preservation in existing code (VB6 is case-insensitive but diff tools are not), Option Explicit requirement, Hungarian notation with scope prefix plus type prefix (mstr/mint/mcur for module-level in .bas; m_str/m_int/m_cur for module-level in .cls; gstr/gint for global; str/int/cur for parameters and locals), file header blocks for .cls modules with 80-hyphen delimiters, comment-per-field convention, Property Get/Let/Set patterns without public fields, ByVal/ByRef explicit declarations, Long over Integer for performance and overflow safety, preservation of Windows-1252 encoding and CRLF line endings, and never editing .frx files manually due to binary offset corruption. Activates for any Visual Basic 6 development task, code review, refactoring, or new file creation in a VB6 project.
alexcassol/claude-vb6-skills · ★ 0 · Code & Development · score 70

Install: claude install-skill alexcassol/claude-vb6-skills

# VB6 Guidelines VB6 is not VB.NET. It is not C#. It is not VBA. The rules below reflect what the VB6 compiler (1998) requires and what the COM ecosystem expects. ## 1. Case-preservation is absolute in existing code VB6 is case-insensitive at the compiler level. Diff tools (Git, GitHub, GitLab, Bitbucket, code review tools) are case-sensitive. Changing the case of an identifier in existing code pollutes pull requests with ghost changes, hides the real diff, and breaks `git blame`. **Absolute rule:** when editing existing code, the case of every identifier stays exactly as it is. No exceptions. This applies to: - Variables and parameters (`m_StrName` stays `m_StrName` even if the current convention is `m_strName`) - Properties and procedures (`Public Sub ReadFile` is not "normalized" to `ReadFile` if it is already `ReadFile`) - Keywords (`If`/`Then`/`End If` — preserve as written; the IDE may have normalized different files differently) - Type names (`As String`, `As Long`) - Constants (`vbCrLf` vs `vbCRLF`) - References to module and class names **When you may use the "correct" case:** - **New** code (new procedure, new module, new variable) - When the user explicitly asks for normalization **When you may not, even when it looks obvious:** - "Taking advantage" of a bugfix commit to normalize - "Since I'm already here" during a legitimate refactor of something else - Cosmetic cleanup without explicit request The cost of polluting the diff outweighs the value o