Đây có phải là một tình huống chính xác để sử dụng một hằng số?

Vì vậy, giáo sư của tôi đã đưa ra một số phản hồi về một dự án mà tôi đang thực hiện. Ông đã cập bến một vài điểm cho mã này:

if (comboVendor.SelectedIndex == 0) {
  createVendor cv = new createVendor();
  cv.ShowDialog();
  loadVendors();
}

Đây là trong một bộ xử lý "thay đổi chỉ mục" combobox. Nó được sử dụng khi người dùng muốn tạo một nhà cung cấp mới, tùy chọn hàng đầu của tôi (chỉ số 0, không bao giờ thay đổi) mở hộp thoại "Tạo nhà cung cấp mới". Vì vậy, nội dung của hộp tổ hợp của tôi kết thúc như thế này:

Create New Vendor...
Existing Vendor
Existing Vendor 2
Existing Vendor 3

Vấn đề của anh ấy là với mã dòng đầu tiên:

if (comboVendor.SelectedIndex == 0)

Anh ta tuyên bố rằng 0 nên là một hằng số, và thực sự đã đánh dấu tôi vì điều đó. Ông tuyên bố tôi không nên sử dụng chữ trong mã của tôi.

Vấn đề là, tôi không hiểu tại sao tôi muốn biến mã đó trong tình huống đó thành một hằng số. Chỉ số đó sẽ không bao giờ thay đổi, cũng không phải là thứ mà bạn sẽ cần phải điều chỉnh. Có vẻ như lãng phí bộ nhớ để giữ một 0 trong bộ nhớ được sử dụng cho một tình huống rất cụ thể và không bao giờ thay đổi.

Cách thực sự chính xác để làm điều này trong C # là không dựa vào thứ tự của ComboItems .

public partial class MyForm : Form
{
    private readonly object VENDOR_NEW = new object();

    public MyForm()
    {
        InitializeComponents();
        comboVendor.Items.Insert(0, VENDOR_NEW);
    }

    private void comboVendor_Format(object sender, ListControlConvertEventArgs e)
    {
        e.Value = (e.ListItem == VENDOR_NEW ? "Create New Vendor" : e.ListItem);
    }

    private void comboVendor_SelectedIndexChanged(object sender, EventArgs e)
    {
        if(comboVendor.SelectedItem == VENDOR_NEW)
        {
            //Special logic for selecting "create new vendor"
        }
        else
        {
            //Usual logic
        }
    }
}

Thứ tự trong hộp tổ hợp có thể thay đổi. Điều gì sẽ xảy ra nếu bạn thêm một tùy chọn khác như "Tạo nhà cung cấp đặc biệt ..." trước khi "Tạo Vender mới ..."

Ưu điểm của việc sử dụng hằng là nếu có nhiều phương thức phụ thuộc vào thứ tự của hộp tổ hợp, bạn chỉ phải thay đổi hằng và không phải tất cả các phương thức nếu điều này không thay đổi.

Sử dụng một hằng số cũng dễ đọc hơn một nghĩa đen.

if (comboVendor.SelectedIndex == NewVendorIndex)

Hầu hết các ngôn ngữ được biên dịch sẽ thay thế hằng số tại thời gian biên dịch, do đó không có hình phạt hiệu suất.

Tình huống này bạn mô tả là một cuộc gọi phán xét, cá nhân tôi sẽ không sử dụng nó nếu nó chỉ được sử dụng một lần và đã có thể đọc được.

Tuy nhiên, câu trả lời thực sự là anh ấy đã chọn nó để dạy cho bạn một bài học.

Đừng quên rằng anh ấy là một giáo sư, công việc của anh ấy là dạy cho bạn viết mã và thực hành tốt nhất.

Tôi muốn nói rằng anh ấy đang làm một công việc khá tốt.

Chắc chắn anh ta có thể trở nên tuyệt đối một chút nhưng tôi chắc chắn bạn sẽ suy nghĩ lại trước khi sử dụng số ma thuật.

Ngoài ra, anh ta có đủ sức để bạn tham gia một cộng đồng trực tuyến về các lập trình viên chỉ để tìm hiểu những gì được coi là thực hành tốt nhất trong tình huống này.

Ngả mũ với giáo sư của bạn.

[...] Tùy chọn hàng đầu của tôi (chỉ số 0, không bao giờ thay đổi) mở hộp thoại "Tạo nhà cung cấp mới".

Thực tế đó bạn phải giải thích rằng chứng minh tại sao bạn nên sử dụng hằng số. Nếu bạn giới thiệu một hằng số như thế NEW_VENDOR_DIALOG, mã của bạn sẽ tự giải thích nhiều hơn. Ngoài ra, trình biên dịch tối ưu hóa các hằng số, do đó sẽ không có thay đổi về hiệu suất.

Viết chương trình cho lập trình viên, không phải trình biên dịch. Trừ khi bạn đặc biệt cố gắng tối ưu hóa vi mô, điều này dường như không giống bạn.

Anh ta tuyên bố rằng 0 nên là một hằng số, và thực sự đã đánh dấu tôi vì điều đó.

Tôi đồng ý. Việc sử dụng số 0 ở đây là "ma thuật". Hãy tưởng tượng rằng bạn đang đọc mã này lần đầu tiên. Bạn không biết tại sao số 0 lại đặc biệt và nghĩa đen không cho bạn biết lý do tại sao số 0 lại đặc biệt. Nếu thay vào đó bạn nói if(comboVendor.SelectedIndex == CreateNewVendorIndex)thì nó trở nên cực kỳ rõ ràng đối với người đọc lần đầu tiên về ý nghĩa của mã.

Ông tuyên bố tôi không nên sử dụng chữ trong mã của tôi.

Đó là một vị trí cực đoan; một vị trí thực tế sẽ nói rằng việc sử dụng chữ là một lá cờ đỏ chỉ ra rằng mã có thể không rõ ràng như nó có thể. Đôi khi nó là thích hợp.

Vấn đề là, tôi không hiểu tại sao tôi muốn biến mã đó trong tình huống đó thành một hằng số. Chỉ số đó sẽ không bao giờ thay đổi

Rằng nó sẽ không bao giờ thay đổi là một lý do tuyệt vời để biến nó thành một hằng số . Đó là lý do tại sao các hằng số được gọi là hằng số; bởi vì họ không bao giờ thay đổi

cũng không phải là một cái gì đó mà bạn sẽ cần phải điều chỉnh.

Có thật không? Bạn không thể thấy bất kỳ tình huống nào trong đó ai đó có thể muốn thay đổi thứ tự của mọi thứ trong hộp tổ hợp?

Việc bạn có thể thấy một lý do tại sao điều này có thể thay đổi trong tương lai là một lý do tốt để không biến nó thành một hằng số. Thay vào đó nó phải là một trường số nguyên tĩnh không chỉ đọc. Một hằng số phải là một số lượng được đảm bảo giữ nguyên cho mọi thời đại . Pi và số nguyên tử của vàng là hằng số tốt. Số phiên bản không có; họ thay đổi mọi phiên bản. Giá vàng rõ ràng là một hằng số khủng khiếp; nó thay đổi từng giây. Chỉ thực hiện liên tục những điều mà không bao giờ thay đổi .

Có vẻ như lãng phí bộ nhớ để giữ một 0 trong bộ nhớ được sử dụng cho một tình huống rất cụ thể và không bao giờ thay đổi.

Bây giờ chúng ta đến mấu chốt của vấn đề.

Đây có lẽ là dòng quan trọng nhất trong câu hỏi của bạn bởi vì nó chỉ ra rằng bạn có một số hiểu biết sâu sắc về (1) bộ nhớ và (2) tối ưu hóa. Bạn đang ở trường để học, và bây giờ sẽ là thời điểm tuyệt vời để hiểu đúng về các nguyên tắc cơ bản. Bạn có thể giải thích chi tiết lý do tại sao bạn tin rằng "thật lãng phí bộ nhớ để giữ một số không trong bộ nhớ" không? Trước hết, tại sao bạn tin rằng tối ưu hóa việc sử dụng bốn byte bộ nhớ trong một quy trình với ít nhất hai tỷ byte lưu trữ có thể định địa chỉ người dùng có liên quan? Thứ hai, chính xác những tài nguyên nào bạn tưởng tượng đang được tiêu thụ ở đây ? Bạn có ý nghĩa gì khi "bộ nhớ" bị tiêu thụ?

Tôi quan tâm đến câu trả lời cho những câu hỏi này trước tiên vì chúng là cơ hội để bạn tìm hiểu cách hiểu của bạn về tối ưu hóa và quản lý bộ nhớ là không chính xác, và thứ hai bởi vì tôi luôn muốn biết tại sao người mới bắt đầu tin những điều kỳ quái, để tôi có thể thiết kế công cụ tốt hơn để dẫn dắt họ có niềm tin chính xác.

Anh ấy đúng. Bạn đúng. Bạn sai rồi.

Anh ấy đúng, về mặt khái niệm, những con số ma thuật nên tránh. Các hằng số làm cho mã dễ đọc hơn bằng cách thêm ngữ cảnh vào số có nghĩa là gì. Trong tương lai khi ai đó đọc mã của bạn, họ biết tại sao một số cụ thể được sử dụng. Và nếu bạn cần thay đổi một giá trị ở đâu đó, tốt hơn hết là thay đổi nó ở một nơi thay vì cố gắng săn lùng mọi nơi sử dụng một số cụ thể.

Điều đó đang được nói, bạn đã đúng. Trong trường hợp cụ thể này, tôi thực sự không nghĩ rằng một hằng số được bảo hành. Bạn đang tìm kiếm mục đầu tiên trong danh sách, luôn luôn bằng không. Nó sẽ không bao giờ là 23. Hoặc -pi. Bạn đang đặc biệt tìm kiếm số không. Tôi thực sự không nghĩ rằng bạn cần làm lộn xộn mã bằng cách biến nó thành một hằng số.

Tuy nhiên, bạn đã sai khi cho rằng một hằng số được mang theo như một biến số, 'sử dụng bộ nhớ'. Một hằng số là có cho con người và trình biên dịch. Nó báo cho trình biên dịch đặt giá trị đó vào vị trí đó trong quá trình biên dịch, trong trường hợp bạn đã đặt một số bằng chữ. Và ngay cả khi nó mang theo hằng số trong bộ nhớ, đối với tất cả các ứng dụng đòi hỏi khắt khe nhất, sự mất hiệu quả thậm chí sẽ không thể đo lường được. Lo lắng về việc sử dụng bộ nhớ của một số nguyên chắc chắn rơi vào 'tối ưu hóa sớm'.

Tôi đã thay thế 0bằng một hằng số để làm cho ý nghĩa rõ ràng, chẳng hạn như NewVendorIndex. Bạn không bao giờ biết nếu đơn đặt hàng của bạn sẽ thay đổi.

Đó là tổng số ưu tiên của giáo sư của bạn. Thông thường, bạn chỉ sử dụng một hằng số nếu nghĩa đen sẽ được sử dụng nhiều lần, bạn muốn làm cho người đọc thấy rõ mục đích của dòng này là gì, hoặc nghĩa đen của bạn sẽ có thể được thay đổi trong tương lai và bạn chỉ muốn thay đổi nó ở một nơi Tuy nhiên, trong học kỳ này, giáo sư là ông chủ, vì vậy tôi sẽ làm điều đó từ bây giờ trong lớp học đó.

Đào tạo tốt cho thế giới doanh nghiệp? Hoàn toàn có thể.

Thành thật mà nói, trong khi tôi không nghĩ rằng mã của bạn là thực tiễn tốt nhất, thì gợi ý của anh ấy thật ra hơi kỳ cục.

Một thực tế phổ biến hơn cho một combobox .NET là cung cấp cho mục "Chọn .." một giá trị trống, trong khi các mục thực tế có các giá trị có ý nghĩa, sau đó thực hiện:

if (string.IsNullOrEmpty(comboVendor.SelectedValue))

thay vì

if (comboVendor.SelectedIndex == 0)

Anh ấy không sai khi nhấn mạnh giá trị của việc sử dụng hằng và bạn không sai khi sử dụng chữ. Trừ khi anh ta nhấn mạnh rằng đây là phong cách mã hóa dự kiến, bạn không nên đánh mất dấu ấn khi sử dụng chữ vì chúng không có hại. Tôi đã thấy các chữ được sử dụng ở khắp mọi nơi rất nhiều lần trong mã thương mại.

Quan điểm của ông là tốt mặc dù. Đây có thể là cách của anh ấy để khiến bạn nhận thức được lợi ích của hằng số:

1-Họ bảo vệ mã của bạn ở một mức độ nào đó khỏi sự giả mạo tình cờ

2-Như @DeadMG đã nói trong câu trả lời của mình, nếu sử dụng cùng một giá trị theo nghĩa đen ở nhiều nơi, nó có thể xuất hiện với một giá trị khác do nhầm lẫn - Vì vậy, hằng số giữ nguyên tính nhất quán.

3-Hằng số bảo tồn loại, vì vậy bạn không phải sử dụng cái gì đó như 0F có nghĩa là không.

4-Để dễ đọc, COBOL sử dụng ZERO làm từ dành riêng cho giá trị 0 (nhưng cũng cho phép bạn sử dụng số không theo nghĩa đen) - Vì vậy, việc đặt một giá trị đôi khi là hữu ích, ví dụ: (Nguồn: ms-Constants

class CalendarCalc
{
    const int months = 12;
    const int weeks = 52; //This is not the best way to initialize weeks see comment
    const int days = 365;

    const double daysPerWeek = (double) days / (double) weeks;
    const double daysPerMonth = (double) days / (double) months;
}

hoặc như trong trường hợp của bạn (như thể hiện trong câu trả lời @Michael Krussel)

Bạn sẽ chỉ cần đặt nó trong một hằng số nếu nó có đạo hàm phức tạp, hoặc nếu nó lặp đi lặp lại thường xuyên. Khác, một nghĩa đen là tốt. Đặt mọi thứ trong một hằng số là tổng số quá mức cần thiết.

Trên thực tế, như đã đề cập, nếu vị trí của nó thay đổi thì sao? Những gì bạn có thể / nên làm là sử dụng một mã, thay vì dựa vào chỉ mục.

Vì vậy, khi bạn tạo danh sách lựa chọn của mình, nó sẽ kết thúc bằng html như

<select>
    <option value='CREATE'>Create New Vendor...</option>
    <option value='1'>Existing Vendor</option>
    <option value='2'>Existing Vendor 2</option>
    <option value='3'>Existing Vendor 3</option>
</select>

Sau đó, thay vì kiểm tra selectedIndex === 0, hãy kiểm tra xem giá trị CREATECODEsẽ là một hằng số và sẽ được sử dụng cho cả thử nghiệm này và khi tạo danh sách chọn.

Tôi sẽ thoát khỏi nó hoàn toàn. Chỉ cần đặt một nút tạo mới bên cạnh danh sách hộp tổ hợp. Nhấp đúp vào một mục trong danh sách để chỉnh sửa hoặc nhấp vào nút. Không có chức năng mới được chôn trong hộp tổ hợp. Sau đó, số ma thuật được loại bỏ hoàn toàn.

Nói chung, bất kỳ số chữ nào trong mã phải được định nghĩa là một hằng số để đặt bối cảnh xung quanh số đó. Không có nghĩa là gì? Trong trường hợp này 0 = NEW_VENDOR. Trong các trường hợp khác, nó có thể có nghĩa là một cái gì đó khác nhau, vì vậy nó luôn luôn là một ý tưởng tốt cho khả năng đọc và bảo trì để đặt một số bối cảnh xung quanh nó.

Như những người khác đã nói, bạn nên sử dụng một số phương pháp khác với số chỉ mục để xác định mục hộp tổ hợp tương ứng với một hành động nhất định; hoặc, bạn có thể tìm thấy chỉ mục với một số logic lập trình và lưu trữ nó trong một biến.

Lý do tôi viết là để giải quyết nhận xét của bạn về "sử dụng bộ nhớ". Trong C #, như trong hầu hết các ngôn ngữ, các hằng số được "gấp" bởi trình biên dịch. Ví dụ, biên dịch chương trình sau và kiểm tra IL. Bạn sẽ thấy rằng tất cả những con số đó thậm chí không được đưa vào IL, chứ đừng nói đến bộ nhớ của máy tính:

public class Program
{
    public static int Main()
    {
        const int a = 1000;
        const int b = a + a;
        const int c = b + 42;
        const int d = 7928345;
        return (a + b + c + d) / (-a - b - c - d);
    }
}

kết quả IL:

.method public hidebysig static 
    int32 Main () cil managed 
{
    .maxstack 1
    .locals init (
        [0] int32 CS$1$0000
    )

    IL_0000: nop
    IL_0001: ldc.i4.m1  // the constant value -1 to be returned.
    IL_0002: stloc.0
    IL_0003: br.s IL_0005

    IL_0005: ldloc.0
    IL_0006: ret
}

Vì vậy, cho dù bạn sử dụng hằng số, một chữ hoặc một kilobyte mã bằng số học không đổi, giá trị được xử lý theo nghĩa đen trong IL.

Một điểm liên quan: Gấp liên tục áp dụng cho chuỗi ký tự. Nhiều người tin rằng một cuộc gọi như thế này gây ra quá nhiều kết nối chuỗi không cần thiết, không hiệu quả:

public class Program
{
    public static int Main()
    {
        const string a = "a";
        const string b = a + a;
        const string c = "C";
        const string d = "Dee";
        return (a + b + c + d).Length;
    }
}

Nhưng hãy kiểm tra IL:

IL_0000: nop
IL_0001: ldstr "aaaCDee"
IL_0006: callvirt instance int32 [mscorlib]System.String::get_Length()
IL_000b: stloc.0
IL_000c: br.s IL_000e
IL_000e: ldloc.0
IL_000f: ret

Dòng dưới cùng: Toán tử trên biểu thức không đổi dẫn đến biểu thức không đổi và trình biên dịch thực hiện tất cả các tính toán; nó không ảnh hưởng đến hiệu suất thời gian chạy.