Programcılar değişken kapsamdan önce, her şeyin global olduğu yerde ne yaptı?

Bu yüzden, temel bir yöntemim, değişkenleri tanımlayacağım birkaç veri tipim olduğu ve bir tür döndürmeyen alt işlemlere sahip olabileceğim (esas olarak geçersiz yöntemler) yeteneğim olan, görünüşte archiac dili (PowerOn adı verilen) ile uğraşmak zorundayım. ne de herhangi bir tartışmayı kabul etmez. Buradaki sorun, HERŞEYİN küresel olmasıdır. Bu tür dilleri okudum, ancak kitapların çoğu "Tamam, at ve araba kullanmak için kullanıyoruz, ama şimdi, işte araba, öyleyse hadi bunun üzerinde çalışmayı öğrenelim!" O günleri ASLA tekrar yaşayamayacağız " . İtiraf etmeliyim ki, zihin kapsam ve kapsam dışında düşünmek için mücadele ediyor .

İyi buradayım. Ben en iyi birkaç genelinde başka bir şey küresel değişkenleri yönetmek anlamaya çalışıyorum açık yöntemlerle. Evet, fordöngüler için yineleyiciler bile , kendimi kodumun farklı bölümlerinde geri dönüşümünü bulduğum küresel olarak tanımlanmalı.

Sorum: Bu tür deneyime sahip olanlar için, programcılar küresel bir oyun alanında çok sayıda değişkeni nasıl ele aldılar? Bunun sadece zihinsel bir hokkabazlık numarası haline geldiğini hissediyorum, ancak bilinen herhangi bir yaklaşım olup olmadığını bilmek isterim.

Düzgün tutmak için bir tür zihinsel defter tutma numarasına (adlandırma kuralları, vb.) İhtiyacınız olacak. Ayrıca, belge, belge, belge. Tüm değişkenler küresel olduğu için mümkünse hepsi listelenmiş tek bir belgeye sahip olun.

Geçici işlemler için her zaman kullandığınız az sayıda değişkene sahip olmaya çalışın ve onların geçici olduğunu unutmayın. Sürekli olarak aynı olanları tekrar kullanarak, nerede olduklarının geçerli olup olmadıklarını takip etme alışkanlığına sahip olacaksınız.

Ayrıca, belgelere bakmak ve değişken adlarının ne kadar uzun olabileceğini ve kaç karakterin benzersiz olduğunu bildiğinizden emin olmak istersiniz. PowerOn hakkında HİÇBİR ŞEY biliyorum, ancak yalnızca küresel bir kapsamı olacak kadar arkaikse, tanımlayıcılar üzerinde sınırlı bir benzersiz uzunluk olması mümkündür.

Daha önce uzun tanımlayıcıları olan, ancak tanımlayıcıları yalnızca ilk 8 karakterde benzersiz olan şeyleri gördüm. Böylece RonnyRayGun ve RonnyRayBlaster'a sahip olabilirsiniz ve bunlar aslında SAME değişkenidir. Bu gibi durumlarda değişken adlarını 'benzersiz' sınırın altında tutmanızı tavsiye ederim, böylece yanlışlıkla çarpışma olasılığınız azalır.

Bilgi sözlüğü.

Merkezi bir depoda (genellikle baş programcının ofisi), her global değişken için bir sayfa içeren gevşek bir cilt vardı. Sayfada adı, tanımı, amacı ve hangi rutinleri belirledi veya kullandı.

Mikroskobik RAM'li erken gömülü sistemler benzer bir soruna ve benzer bir çözüme sahipti. Lider programcı, hangi RAM'lerin hangi modüller tarafından hangi amaçlar için kullanıldığını gösteren, her bir byte'a kadar ana RAM haritasını korudu. Özel bir RAM tahsisine ihtiyaç duyan programcılar, konuyu tartıştıktan sonra uygun notebook girişini yapan ve adama RAM'ini veren lider programcıya gittiler. (Öncü programcıyı temizlemeden RAM bayt alan programcının yerinde olmak istemediniz. Bana bu konuda güvenin.)

Bu problem, programcıların BASIC'in ilk sürümlerinde büyük sistemler inşa etmek zorunda kaldıklarında da ortaya çıktı. Şahsen benim için Info (Henco, Inc. New Jersey'in ürünü - HOPEFULLY şimdi çoktan gitti!) Adlı çok ilkel bir “veritabanı” yöneticisi kullanırken ortaya çıktı. Bu dillerin her ikisinin de çok sınırlı bir değişken isim kelimesi vardı.

Programlama dillerinin blok kapsamındaki yükselişi, daha hızlı, daha büyük makinelerin ortaya çıkmasıyla aynı zamana denk geldi ve bu bir tesadüf değil. Eski bilgisayarlarda RAM MB, kB veya hatta bayt olarak ölçülmüştür; Program büyüdükçe karıştırılmayacak kadar çok değişkene sahip olmak bile mümkün değildi, çünkü programlar hiç bu kadar büyük olmamıştı . Programlama dillerindeki ilerlemeler, genellikle insanlar eski programlama alışkanlıklarının arena daha da büyüdüğünde ölçeklenemediğini fark ettiğinde; Blok kapsamı, programcıların kendi sınırlı hafızalarına karşı bir savunma mekanizması olarak icat edildi.

Bilgisayarlar aynı zamanda, bilgisayarların fevkalade pahalı olduğu durumlarda çok daha nadir ve egzotik bir faaliyetti ve ilk başta yalnızca matematiksel olarak eğimli ve usta bireylerin programcı haline gelmesi iyi olabilirdi (bu tür karşılaştırmalar test etmek için pratik olmasa da ve kesinlikle politik olarak kışkırtıcı olsa da). İlk günlerde, insanları ilk elden almaya ikna etmek için yazılım genellikle bir bilgisayarla ücretsiz olarak gönderilirdi; kurumsal kullanıcıların bile kendi programlarını yazma girişiminde bulunacağı düşüncesi ilk başlarda bilinmiyordu.

Tanrım, bu yıllar önce (kabarcıklı anılar :)).

Bahsettiğiniz dili bilmiyorum, fakat genel olarak sahip olduğumuz şeye adapte olduk. Gerçekten çok büyük bir sorun değildi. mIORead1Bir dosyadan veri okumak için bir işleyiciniz varsa ya da bir dosyadan veri okumak için bir işleyiciniz varsa , altta veya işlede sıkça yer alan (kısa biçimde, bu günlerde bayt sayısı değerliydi) var olan adlara daha fazla dikkat etmeniz gerekiyordu. sayaç, kendi sisteminiz tarafından ne için olduklarını bildiğiniz, eğer tekrar kullanılabilirlerse, vb. Daha sertti (o zamanlar kask ya da eldiven yok) :-)

Bu, PLC programlamaya oldukça benzer, ancak modern PLC'ler artık bir program için yerel olan "etiketlere" (aka değişkenler) sahip olmanıza izin veriyor. Yine de birçok insan sadece tüm global etiketleri kullanarak program yapar.

Bunu yapacaksanız, yapılandırılmış bir adlandırma kuralı kullanmanız gerektiğini öğrendim. Örneğin: Motor1_DriveContactor_Run. Diliniz yapıları (bazen kullanıcı tanımlı türler olarak da bilinir) destekliyorsa, bunları aşağıdaki gibi yapılandırılmış bir veri hiyerarşisi oluşturmak için de kullanabilirsiniz Motor[1].DriveContactor.Run.

Bu her şeyi organize tutar ve genellikle zekâ size yardımcı olacak kadar yeterlidir.

Aslında her şeyin global olduğu Authorware adlı bir dilde programlamayı öğrendim. Neyse ki, Dizileri vardı ve belirli bir noktadan sonra genel nesnelere benzer olan Listeler adı verilen bir şey.

Bir Authorware programı aslında fiziksel bir yapıya sahipti (Authorware bir akış şeması metaforuna dayanıyordu) ve betik dili eski stil Pascal'a dayanıyordu. Yaptığımız şey fiziksel yapıyı Dizideki dizinlerle ilişkilendirmekti ve çoğu zaman Dizi dizinleri kullandığımız fiziksel parça için yerel bir nesne olarak ele alacağımız Listeleri içerecekti.

Authorware e-learning için tasarlandı, bu yüzden sahip olduğumuz simgelerden biri de bir Sayfa oldu. Sayfalar bir Çerçeveye eklenir. Bu nedenle, Sayfa 1 için, dizin 1'deki bazı Array'lere bakardık (Authorware 1-indexed) ve sözde nesne olarak hareket edecek bir Listenin depolanacağı o sayfanın verilerini çıkardık. Daha sonra Sayfa, nesnenin "özelliklerini" isme göre çıkaracak bir mantığa sahip olacaktır. Nesneler gibi bir şeye sahip değilseniz, ancak Dizileriniz varsa, hangi verilerin nereye gittiğine dair basitçe bir sözleşmeniz olabilir.

Veritabanından veri alırken ve bağımlılık enjeksiyonunu yaptığımızda yaptığımız işlerden hiç de farklı değil, ancak her şeyin gerçekten global olması dışında, her şeyi küçük kutulara koymayı ve yalnızca bir tanesine bakmayı seçiyorsunuz. Şu an için endişe duyuyorum.

Ne yapmaya çalıştığınıza ve dilinizin desteklediğine bağlı olarak bu, en azından işleri daha yönetilebilir parçalara bölmenize yardımcı olabilir.

Üniversitedeyken uzunca bir süre küresel değişkenlerin neden olduğu bir hatalar ve kod sürdürme sorunları olan “Küresel Değişken Sorun” hakkında bilgi verildi.

Bazı değişkenler diğerlerinden daha tehlikelidir.

Güvenli : Kontrol akışını etkilemeyen değişkenler, örneğin, LastName

Tehlikeli : Programın kontrol akışını etkileyen herhangi bir değişken, örneğin DeliveryStatus

İlk önce en tehlikeli:

• Bileşik durumu (mod ve alt mod)
• Bileşik değerler (toplam, alt toplam)
• Tek durum (mod)
• Tek değerler (sayım)

"Genel değişken sorununu" önlemek için yapmanız gerekenler

• Her değişkeni ve işlevi belgeleyin .
• Kaynak kodun aynı bölümünde ilgili değişkenleri birbirine yakın tutun (bunları kullanan kodla birlikte).
• "Tehlikeli" değişkenleri gizleyin, böylece diğer programcılar varlıklarını bilmezler. Bunları doğrudan, özellikle kodun diğer bölümlerinde kullanmaktan kaçının.
• Tehlikeli değişkenleri okuyan / yazan fonksiyonlar sağlayın (diğer programcıların buna ihtiyacı yoktur).

İçin kodunuzu yapılandırırken hiçbir yapı dili, kullanım yorum ve adlandırma kurallarına de kullanılabilir olduğunda,:

/* --------------------------- Program mode ------------------------ */

var Mode_Standard = 1;      // Normal operation (SubMode unused)
var Mode_Backup   = 2;      // Backup mode      (SubMode is backup device)

var BackupMode_Disk = 1;    // SubMode: Backup to disk
var BackupMode_Tape = 2;    // SubMode: Backup to tape

var MainMode = Mode_Standard;
var SubMode = 0;

function Mode_SetBackup(backupMode)
{
    MainMode = Mode_Backup;
    SubMode = backupMode;
}

function Mode_SetStandardMode()
{
    MainMode = Mode_Standard;
    SubMode  = 0;
}

function Mode_GetBackupMode()
{
    if (MainMode != Mode_Backup)
        return 0;

    return SubMode;
}

/* --------------------------- Stock Control ------------------------ */

var Stock_Total =  123;      // Total stock       (including RingFenced)
var Stock_RingFenced = 22;   // Ring-fenced stock (always less than total)

// Adds further ring-fenced stock 
function Stock_AddRingFenced(quantity)
{
    Stock_Total      += quantity;
    Stock_RingFenced += quantity;
}

/* ------------------------- Customers ----------------------- */

var Customer_FirstName = "Tony";
var Customer_LastName  = "Stark";

Nasıl yaptıklarını bilmiyorum.

Ancak modern OOP dillerinin isimlendirme çarpışmasında çok benzer bir sorunu olduğunu düşünüyorum .

Çözüm, ad alanını benimsiyor . Bu soyut bir kavramdır, ancak birçok uygulama tarafından yaygın olarak kabul edilmektedir (Java paketleri, .NET ad alanı, Python modülleri).

Kullandığınız dil, adlandırma uzunluğu hakkında çok sınırlı bir sınırlamaya sahip değilse, ad alanını iyi bir değişken adlandırma için uygulayabilirsiniz.

Böylece değişken ismi değişken kapsamını da temsil eder.

Bunun gibi bir adlandırma modeli tanımlamaya çalışın: order_detail_product_code, order_detail_product_unit_price. Veya geçici sayıcılar veya takaslar için: tmp_i, tmp_swap.

Dillerde tüm değişkenler geneldi (bir çift kullandım) değişken adlandırma kurallarını kullanıyorduk. Örneğin: Eğer bir değişkeni global olarak kullanmak istersem, "m_" veya "_" ön ekini kullanabilirim. Tabii ki bu hala bu disipline sahip olan geliştiricilere güveniyor